rhiaro
commented
8 years ago The case I had in mind for multiple inboxes advertised on one resource was a document with multiple authors, where each author's inbox is listed so they all get notifications about interactions with the document. In this case, there's no need for the inboxes to be kept in sync, as they could each have other stuff coming in from other places as well.
This makes sense from a sending/receiving perspective, but you're right that it's weird for a consumer which is starting at the document (rather than any of the author profiles), and we're currently not saying anything in the consuming section about what to do when multiple inboxes are discovered.
Moving issue from #6
This has the nice property that when I'm consuming notices, I only need to read one of the many inboxes of a resource. But it has a bad failure mode. What if a sender didn't read this line carefully, or what if a sender crashed or lost network before sending all of the notices. Now some consumers will see it and others will not, unpredictably.
If you keep this MUST, I think you need to say, at least, that inboxes SHOULD all know about each other and perform a Byzantine consistency algorithm so they eventually become consistent. Otherwise these errors are just going to pile up and keep confusing everybody.
A better solution is to say either (1) there MUST be only one inbox (and if you want several, make that one be a service that makes sure each of the several desired inboxes gets the message eventually, or (2) say the sender can send to ANY of the inboxes, and the consumer MUST read all of them if it wants to get all of the notices.
(Also, if you do keep the MUST, then you need to spell out exactly what 'deduplications means'. Are "http://www.w3.org" and "http://www.w3.org/" the same thing? or "http://WWW.w3.org"? Details of how to do this are spelled out here: https://tools.ietf.org/html/rfc3986#page-38 . But just get rid of folks sending to all of them. )