yes, friendsunhosted and sharedstuff did it that way. it’s not ideal, and it’s maybe the biggest architectural problem of the web: the lack of a way to send a “ping”. for transactions in a tab, this is exactly the same problem as for posting comments to a blog thread. in general, from a blogosphere perspective, this is known as linkback, see for instance http://blog.michielbdejong.com/entry/four-simple-tips-for-web-page-providers-1-2.html (third chapter of that post). i think every user should run a polyglot linkback server. that way, you would have a way to alert other people in a tab that you published a new transaction.
sockethub doesn’t, by itself, provide a linkback mechanism. but it does, if you combine it with a chat server. actually you could use a mailserver instead, so that you can send messages to the other people while they are not connected to sockethub.
a big drawback of this is of course that there is no well-defined way to contact a user, other than human-readable text. so either:
you set up a custom chat server as a centralized walled garden, and grouptabs only works properly for people who connect to that one specific server
you define and publish the format of the ping messages you send, or use an existing standard like pubsubhubbub or WebMention. then everybody can run their own grouptabs-ping server
you send out human-readable emails or xmpp messages with a hyperlink in them, and the user has to click on that to get to the updated tab with the added transaction
Coincidentally, I pitched some ideas about this to Nick yesterday.
For example–as soon as Sockethub supports persistent sessions and background tasks–what if we’d use Sockethub in the app in order to send a human-readable HTML email with embedded activity stream objects in the source? Then Sockethub could go ahead and put activity stream notifications in a special folder on your remoteStorage, which in turn the app or even client lib can automatically read and remove as soon as they’re processed. Sounds a bit weird I guess, but maybe we can creatively combine tech here in order to come up with a novel solution to the problem.
You could even build a complete social network on top of email and distributed apps and storages with this. It’s probably a stupid, impractical idea, not even speaking of better not using unencrypted email as main transport mechanism, but hey, let’s do some more brainstorming before we declare that there are only so many options.
If the protocol (spec 03? I don’t know it too well) would specify real-time Operational Transform hooks, through plugins it would be able to virtually emulate any storage engine(rdbms, nosql, flat files, postgres, postgis, couch, monog, neo4j) ever thought of. Wouldn’t it only rely on a transpose operation, i.e. mapping rS’s native APIs to emulated ones?
I wasn’t talking about real-time, and I think it’s not a good technology for real-time apps. We tried it in the past, and it basically failed miserably.
i thought again whether we should add ACLs as an option, now that we have an extensible spec. we could add a :admin level next to the existing :r and :rw which would allow to create and list all :r, :rw, and :admin tokens, which could then also be allowed to be for any path, not just for whole modules. i could imagine it working quite cleanly, whereas the current option is (if we’re honest) a bit of a gfys to developers who need this functionality built in (and have it built in if they opt for one of our two competitors, dropbox.js and googledrive js api).
however, we would have to make it mandatory and not optional, otherwise you get apps that only work with some remoteStorage accounts and not with others, it would clash with implied auth (unless you implement it once with bearer tokens and once with Kerberos), and it would be quite a bit of work (easily one or two months full-time), so we would have to take resources away from other stuff which maybe we want to get working first.
but i think it’s fair to say that this is the one issue that is costing us most market share. maybe we should consider it for the 04 spec
I’m looking at adding collaboration to meute at some point, doing versioning over rss (each participant publishes an rss feed which is basically a git log). Then people can collaborate even if one of them is on Dropbox and the other is on, say, Hoodie.