- From: Harry Halpin <hhalpin@w3.org>
- Date: Sun, 02 Aug 2015 11:40:21 -0400
- To: "public-socialweb@w3.org" <public-socialweb@w3.org>
I'm not sure if we want publish/subscribe protocols to be part of the Social API, but if he we do this work struck me as quite relevant as it allows a third-party (i.e. pubsub or server in our case) to forward messages to subscribers that they can decrypt and Bob can encrypt, but that can't be read by the pubsub server itself. https://en.wikipedia.org/wiki/Proxy_re-encryption Basically, you could then use public keys to track down subscriptions and eliminate spam (see Magic Sigs in Salmon Protocol [1]). In essence, proxies let you delegate your decryption rights without revealing their public key. I think Bob sends the status update to Chris (the pubsub server) to send to folks like Alice (a subscriber) while he is not online. This scheme lets Bob delegate the ability to send the encrypted messages to Alice via the generation of a magic proxy re-encryption key that Bob generates for Chris. Anyways, we will eventually have to think about issues such as spam etc. in the development of the API, but this may be end up in a "Federation" deliverable we may or may not get time to do. cheers, harry [1] http://www.salmon-protocol.org/
Received on Sunday, 2 August 2015 15:40:26 UTC