Headers constrain the content

[melvincarvalho]

A resource MUST advertise only one Inbox

I presume this is primarily meant to mean that if the header is set site wide, the content MUST not contain an inbox discovery link.

Firstly, I think this violates web arch in that the document should not constrain the content. Let's say a site owner decides to set the inbox on a domain, now every time any document is edited, to be in compliance with the REC, the content must check that the header is not set.

Secondly, in RDF a resource can have multiple URIs for a given predicate. This can be partially mitigated with reasoning (functional properties). Ive had the case in the past of having a public inbox on databox, and a private one on localhost. So I can send timeline posts to two places. This is useful.

This could be fixed simply by removing the link header discovery section, or decoupling it from the main spec.

Related: #27

[rhiaro]

I presume this is primarily meant to mean that if the header is set site wide, the content MUST not contain an inbox discovery link.

Not primarily, but equally applies if the inbox has been set in the content, it must not also be set by a header. It also means there shouldn't be two or more inboxes set in the body, or two or more inbox headers set.

Let's say a site owner decides to set the inbox on a domain, now every time any document is edited, to be in compliance with the REC, the content must check that the header is not set.

I see what you mean. This was intended to let publishers know that if assigning multiple inboxes they couldn't be sure which one a sender or consumer would find and use. Perhaps "MUST NOT" was the wrong way of doing this, and we could change the language to make it more informative. Indeed, "publisher" is not a conformance category of the spec, so there is no such thing as a compliant publisher. That is, someone linking to an inbox need not worry about compliance at all. Only the receiver (endpoint acting as an inbox) and sender and consumer need to be compliant.

Secondly, in RDF a resource can have multiple URIs for a given predicate

I think this issue (multiple inboxes on a resource) is nothing to do with the link header, as it's equally achievable by putting them in the body.

The practical upshot is that if there are multiple inboxes set for one resource (whether two in the body, or the body plus the header) then the publisher needs to know they can't rely on senders to send to all of them, or consumers to read from all of them.

However, we did have debate about this early on (see #20) and I'm still on the fence about this constraint. It removed other potential issues like

• the sender MUST send to all of them?
• the consumer MUST read from all of them?
• the same notification MUST be sent if sent to multiple?
• multiple inboxes for one resource MUST be kept in sync?

I think I think it should be at sender/consumer discretion on this point, but I'm not sure practically what implications not being prescriptive in the spec about this would have. Maybe it would be fine.

[melvincarvalho]

If there's one inbox, we send to that.

If there's multiple then the software has to decide, and is out of scope of the spec. We could specify a priority system as used by webfinger, but it seems overkill.

If the language is going to be changed to allow both a link header to be set and an inbox in the content, then #27 remains imho problematic.

I would propose removing the part on link headers, or moving it to another document (e.g. social web protocols). If this is a show stopper for anyone in the WG, or outside of it, it would be good to hear from them.

[rhiaro]

If there's multiple then the software has to decide, and is out of scope of the spec. We could specify a priority system as used by webfinger, but it seems overkill.

I can agree with that.

If this is a show stopper for anyone in the WG, or outside of it, it would be good to hear from them.

I have already explained why it's a show-stopper for me. I'll ping the other people who have mentioned they require this (but I'll ask them to respond in #27, which is more focused on that part of the issue).

[melvincarvalho]

I have already explained why it's a show-stopper for me.

Would you mind capturing the argument in this issue, or repeating it if it was said before? Apologies if I didnt quite get it from your first reply.

I am wondering what prevents you from putting an inbox link in your content?

[rhiaro]

Reasons in #27 (comment)