Aligning ActivitySub and LDN

[rhiaro]

Discovery

• [x] Namespace of inbox
  • LDN is deciding between ldp, solid or ? #13
  • AP has it's own mini vocabulary #30
  • Proposal 1: LDN uses AP's inbox
  • Proposal 2: AP uses LDN's inbox (whatever that is decided to be)
  • Resolved: as:inbox is aliased to ldp:inbox

    Sending

• [x] Media type of sent payload
  • LDN requires receivers to accept application/ld+json POSTs (profile optional)
  • AP senders will send plain JSON with applicaton/activity+json media type
  • Resolved: LDN receivers SHOULD treat incoming POSTs with application/activity+json as equivalent to application/ld+json with the AS2 profile
• [x] The canonical id of notifications
  • LDN has the notification created at the domain of the receiver, and added as a value of ldp:contains.
  • AP has the notification created at the domain of the sender, and a copy of that sent to the receiver, (to be added to the inbox Collection).
  • Proposal: If a notification is received which already has a URI then an LDN receiver should use this URI as the subject and add it to ldp:contains rather than creating a new one.
  • Require the sender is authenticated and the URI is on their domain? (AP does)
  • Is LDP okay with this? ldp:contains can contain pointers to resources elsewhere (according to @sandhawke) but I don't know if they can get there with a POST to the Container..
  • Can AP handle incoming notifications payloads which do not yet exist elsewhere..?
  • Resolved: This is actually not an issue. The notification created by the receiver contains the triples sent whether they exist elsewhere or not. ldp:contains points to the new URIs created, which may return triples with a subject on another domain, as in the AP case. Everything is fine.

    Consuming

• [ ] Relation between inbox and contents
  • LDN uses ldp:contains to allow LDP servers to act as senders without implementation changes.
  • AP inboxes are an as:Collection with as:items as the relation
  • Proposal: ???
• [ ] Returning AS2 payload of individual notifications
  • Plain JSON AP consumers doing a GET on the inbox are going to say Accept: application/activity+json
  • LDN receivers are only required to honour requests for ld+json. We don't say what they should do if there's an accept header with a profile, and I think it's unreasonable to ask them to try to translate all inbox contents to the vocabulary in the profile, and thus if activity+json is requested, we can't ask them to attempt to return anything as AS2.
  • Proposal 1: Sorry AP consumer, you can only have things if you ask for ld+json, and you have to filter out the ones that aren't AS2 on your end (return 415).
  • Proposal 2: Treat activity+json as ld+json+profile and just return JSON-LD. Tough luck if the consumer can't parse it.
  • Proposal 3: Treat activity+json as ld+json+profile and return JSON-LD, but it MUST be in compacted form, so an AP consumer should be able to parse it as JSON.

[rhiaro]

@csarven @cwebber @xray7224, your expertise on your specs would be valuable here. Please look through this when you can!

[rhiaro]

I think we got as far as we could with this one. See also inboxes for consuming bridging.