I’m thinking about how to add collaboration to Grouptabs.
The process could be like this:
- create a new tab
- publish it, which gives you a unique path/id like
- share id/path with others via another channel like email
- others enter id/path and user addresses of people belonging to the group
- app stores list of user addresses to load transactions from
- save transactions in your remoteStorage
- load transactions other people entered from their public remoteStorages
See also https://github.com/xMartin/grouptabs/issues/9#issuecomment-26191682
What do you think? Is this how it is done in Friends Unhosted or Shared Stuff?
How would sockethub fit in?
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
For updates the app can just poll the other public storages, no?
Apart from the human-readable email I don’t find your solutions practical for normal users.
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.
Huh. So, would this also mean it’s possible for Litewrite to become a collective text editor?
I suppose this GitHub - segment-boneyard/socrates: Write and read Markdown in real-time with anyone you want. works similarily with https://www.firebase.com/. As one can watch the storage interactively and in real-time through their Dashboard, it seems remotestorage could in the end be an easy-to-attach key:value store for any app thinkable.
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?
Am I dreaming here?
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.
this also just came up on irc again. a lot of people want to do group permissions on documents (or expect remoteStorage to support it)
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
:rw which would allow to create and list all
: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.
Good point! (And as far as I remember, this one hasn’t been added to the discussion until today.)