LID 2.0 PubSub

From LID Wiki

Placeholder for now. The problem it is supposed to solve is: "How does a LID Client get notified (other than through polling) that some information on a LID Server has changed?" E.g. how do I know that your phone number has changed?

The ambitious plan seems to be a subscription registry modeled after Jabber PubSub and pubsub.com (the latter offering filtered news-items delivered to your mailbox, as it seems). Another example that comes to mind is the Gibson Research[grc.com] mail list system, where the user him/herself can add and remove subscriptions to different mailing lists. The delivery could be either "push" (scheduled by the identity host) or "pull" (like RSS).

Something to consider is how to get early adopters of LID into the subscription loop. If the solution forces them to re-register to get access to subscriptions, this could make them hammer users LID URLs until the user either implements a "PubSub LID Service" or starts filtering out all requests from the Relaying Party who Never Gave Up. This invitation to hammering can be avoided by making the "PubSub LID Service" itself announce to all relevant Relaying Parties when the Service is activated. To know which RPs to announce to, there is the per-user LID Server log which contains URLs of RPs. The log would probably need to store when and which details were given to which RP, and to keep this log for quite long time - at least a few months or more.

So when the user updates a phone number, the LID Server scavenges the log and presents a list to the user with all RPs that should be notified and a big default button "Notify all". Bells and whistles would include per each Relaying Party a chance to de-register those RPs you no longer use '(especially _useful_for_the_developers_ hint,hint! to clean out those for-testing-only RPs you played with in your first week of testing out a new shiny LID identity)' and another action that simply moves a RP to the "Trash bin", keeping the logs but avoiding sending future updates there '(in case a RP has broken and de-registering doesn't work, or if the site causes some annoying messages but no effects each time you poke it with a stick/LID calls)'.

This approach makes the user decide which sites gets updates later on, with the advantage of reminding the user to clean out unused sites (and in the long run saving disk space and bandwidth for involved Servers and RPs!). Allowing the user to grant a subscription at the first contact with a new unknown RP would cancel out the resource-saving side effect. This also allows for a smooth transition to "PubSub-enabling" RPs, while the fully developed PubSub LID-Service could have some subscription registry that is a bit fancier/more efficient than log files. But maybe it would be mostly the same thing, that all RPs would want to subscribe to updates on all info they can get and to have the data "for keeps" in their own customer database (hint: the sheer value of user data and the stockmarket effects of a high registered-user count).