EGreg
commented
9 years ago After implementing Q-to-Q notifications (something along the lines of https://github.com/EGreg/Q/issues/9) we will have the ability for some Q nodes to subscribe to streams on other Q nodes.
But once that is done, we can have users authenticate with Q apps using other, "home" Q apps, and after the new apps would import their avatars, they would subscribing (optional) to firstName, lastName and icon streams hosted by the "home" apps, and autoupdate when they change. So a change in a "home app" would update your avatars everywhere. And this could also be used for other types of streams, such as "location". It's replication basically.
Later we can also implement the "hub" part of pubsubhubbub, namely some number of "intermediate storage" machines that would subscribe to the streams and store them in an encrypted way, so that other subscribers can catch up on the data even if the publisher is offline.
If everyone is on the same Q Domain then no one is external. This can comfortable be the case for a long while before Q becomes distributed.
Here is how Q can become distributed
You can authenticate users on other domains (with baseUrl) by hitting a special action such as Users/authenticate and, if it doesn't have an external userId for you yet, providing an external userId for it to spit back in the future. This external userId should have a prefix that lets you know what baseUrl to hit in the future (eg via a lookup table or directly encoding the baseUrl).
They likewise need to know where to deliver the notifications, ie the baseUrl of the app for which it would POST batched notifications to Streams/notify action. So they would store the baseUrl in the Users.ExternalFrom and ExternalTo rows.
This transaction needs to be encrypted, in a way that both servers can be sure of each other's identity. Presumably they can do this via https and the DNS system for now. (Later maybe they'd additionally use namecoin or something.)
Once authenticated, users on your domain can add contacts on the other domains. The Users.Contact table will have their external userId.
Users can subscribe to their streams, in particular the Streams/authenticated stream
They would have rules that manage some cache table like Users.Authenticated (baseUrl, userId, app, externalUserId) and let them filter contacts by who has authenticated with that domain.
Platform plugin will use this stuff to open iframes to the right domains and make batched requests.
Todo: improve this issue.