Salmon

The FAQ is taken from the Salom Protocol homepage: http://www.salmon-protocol.org/faq Early Internet protocols and systems were vulnerable to trivial forgery, and fixing this after the protocols were widely deployed is painful, partial, and slow. On the other hand, it's also possible to add too much security and make a protocol too restrictive or too complex for large-scale adoption. Salmon tries to find a good balance. Salmon adopts a defense-in-depth strategy, assumes that there will be abuse and spammers, but builds in protocol hooks to make an active in-depth defense both cheap and effective with few false positives. Specifically, spammers can not forge signatures from legitimate users, and it is very hard for them to mint massive numbers of fake identities without detection. So as a first line of defense, anything whose authorship check fails, is simply dropped. We're building this in from the start so that we'll never have an installed base of clients doing things insecurely. Salmon disallows completely anonymous and untraceable messages. It requires pseudonyms from verifiable identity providers. This feature allows receivers to rate limit the messages per hour per pseudonym and per identity provider. (Identity providers themselves have verifiable identities and can gain or lose reputation based on what their users do; every identity provider has to at least have a domain name, raising the bar for spammers significantly, and meaning that simple rate limiting can force the spammers to acquire and "burn" many domain names.) Assuming wide deployment, we expect that spammers will attack Salmon with the same vigor they throw at email. However, Salmon implementors can cheaply and easily deal with the simpler techniques the spammers currently use to inject email. They will also mount active defenses based both on the years of experience in spam-blocking email and the new tools (guaranteed identity, identity providers, distributed reputation) that Salmon enables. All of this is possible to do, and has been done, with closed systems. Salmon provides a way to do this with an open protocol that anyone can implement and anyone can interoperate with.

Yes, the thr:in-reply-to ID can be the ID of a comment (which can itself be a Salmon with a xpost:source element that points at the ultimate source). While the protocol supports threading, recipients can of course flatten salmon in the feeds that they re-publish -- though the thr:in-reply-to element can be used to reconstitute threads as needed.

Salmon is in fact based on and compatible with AtomPub. Salmon greatly enhances interoperability and usability by specifying a distributed identity mechanism for identifying the author and intermediary involved, provides a discovery mechanism, and specifies how things should be linked together. By not requiring pre-registration or federation but still allowing for verifiable identification, it provides a usable, level playing field for all parties involved.

See http://wiki.activitystrea.ms/Cross-Posting.

The payload can define any kind of message, so Salmon can be extended in arbitrary ways. It is already being used to communicate mentions to mentionees. It has also been used to signal cross-site following (by sending a follow message) or to send requests (by sending requests rather than notifications, e.g., a friend request). It is best used when there is not necessarily predefined relationship or subscription between the source and destination; if there is, PubSubHubbub may be a better choice.