Media type application/activity+json

[rhiaro]

If we want this to work with ActivityPub/Sub we need to support AS2 properly by requiring receivers to apply the default @context to any plain JSON posted with this media type, and then treating as JSON-LD.

And also we'd need to allow consumers to request application/activity+json and receivers must treat it the same as ld+json when returning data to AP/S consumers; I thiiiink a regular JSON-LD payload should be fine for plain-JSON AS2 consumers so long as the Content-Type is activity+json in this case (ie. they'd just ignore the @context, but it would also need to be guaranteed in the compact(??) syntax).

This diverges from plain LDP, but maybe that's okay..

[rhiaro]

We have a note to confirm that the profile parameter is supported with the Content-Type but whether or not we need to require support for activity+json or just limit ourselves to only being interoperable with AS2 senders and consumers which use ld+json and profile needs further discussion.

Given that this is a LD-centric spec, supporting plain JSON with activity+json might belong more as a mini bridge spec type thing in SWP or elsewhere.

[akuckartz]

My view: application/activity+json is not a necessary part of the LD world.

[rhiaro]

I've added that receivers should treat incoming notifications with activity+json as equivalent to ld+json with the AS2 profile. This means that at least they won't get dropped based on media type.

I haven't added anything for if consumers request activity+json yet. The main thing is the receiver would need to return a valid AS2 in compact JSON-LD form, but I think this is creeping too far into overspecifying what's in the payload.

[rhiaro]

@akuckartz I understand, but if LDN receivers recognising the media type means that basic activitypub clients can send notifications to LDN inboxes that'd be pretty cool. Hoping for the same in reverse too.

[melvincarvalho]

I would personally remove that mime type as it complicates implementations and the spec. The AS2 spec itself says treating those two as equivalent is something that should be done, for implementors working with AS2. Anyone who consumes AS2 will need to be able to parse those semantics anyway, so it's reasonable to assume they will also have code in place to treat the two mime types as equivalent?

[rhiaro]

@melvincarvalho Right, I agree it complicates things for consuming, which is why I didn't add anything about it in consuming.

Asking receivers to imagine they got ld+json with the profile when they get activity+json doesn't seem like too much of a stretch. Receivers don't (necessarily) know or care about the vocabulary at all.

[melvincarvalho]

@rhiaro thanks for clarifying. In terms of receivers, I see sloph (which is probably going to do this anyway), generic LDP servers that probably would need to be persuaded of the cost benefit, and node-solid-server who I think has decided not to prioritize this. ( solid/solid#83 ). Knowing about the deployment, or potential deployment, of AS2 would help to evaluate the cost benefit.

I will hopefully be writing an implementation based on node solid server too. I think it's possibly a bit early to ask receivers to do this would normally requires a some testing and edge cases. These might have to be part of the test suite too and implementations. Im just thinking that the spec has limited time to publication.

What I think is likely is that those people that are able to process AS2, which is the more complicated branch of the code base, will follow the AS2 spec and treat the two mime types as equivalent.

[rhiaro]

That's why it's a SHOULD not a MUST. I think 'being an existing LDP implementation with no plans to update code' is a valid reason for not doing it.

What I think is likely is that those people that are able to process AS2, which is the more complicated branch of the code base, will follow the AS2 spec and treat the two mime types as equivalent.

Receivers don't need to "process" AS2, they can just treat it as JSON-LD once they know that the activity+json media type means this.

[melvincarvalho]

@rhiaro this is a good point. It is possible to imagine generic LDP endpoints that wish to support LDN but are, not already supporting AS2. You could imagine that they just leave those messages there in the inbox, and the consumer displays them to the user. Or perhaps a robot that understands AS2 will pick them up an process them. None of those things exist right now, but you could imagine a future where they do. It's really nice to imagine such a world.

But just as it is not a stretch to ask generic LDP receivers to implement another mime type. It's not a stretch to ask senders to send the right mime type that LDP implementations already advertise. I think that's the correct way to do this, rather than add more complexity to LDN. If it is a stretch, then I worry about data fidelity, testing and badly formed messages, which are time consuming to deal with.

I personally dread the idea of receiving a bunch of AS2 low fidelity messages each of which has to be analyzed, tested and processed. Experience from other serializations that didnt got the JSON-LD route, such as webfinger, and created a similar JSON format has shown me this turns into a big problem because there ends up being lots of mistakes with everyone sending slightly different JSON. So, as a data point, I would personally not prioritize implementing this without the benefits to be explained.

[melvincarvalho]

Another alternative might be to let AS2 become a REC. Let it get some adoption. Then put the requirement in LDP next.

[csarven]

@melvincarvalho I think if we can take some steps towards alignment between the LDP and AP specs/implementations, both can benefit in the end. This issue and w3c/activitypub#95 is one of those steps. It seems like a small step from both directions. It is not a requirement that implementations do this, hence the SHOULD. This spec could of course leave this out altogether (and likewise AP), but then the commitment from both worlds is that there is less of a chance or rather more work is required to achieve interoperability. It is a trade-off. In the end we want flexible systems, so perhaps this goes in that direction.

[melvincarvalho]

Im open to be persuaded. But I'll ask again, what's the benefit?

Looking at AP I see:

http://www.w3.org/ns/activitypub

Yet it doesnt lead anywhere. So that's a concern. Is anyone using this? Is it likely to become a W3C Recommendation?

Please justify why this is included in the spec. Justifications could be along the lines of.

• Here is an existing REC, or very likely to become an existing REC.
• This has or is likely to achieve a useful amount of adoption.
• Interoperability would help the LDN add to implementations.
• There are current systems using and testing this work.

It's not been explained at any point to implementors why they should do this. The silence here leaves implementors either guessing or feeling there's either no benefit for adding a bespoke non standard mime type.

If there is no explanation along these lines, other than aligning the specs (which is a nice to have, I agree) I'd prefer to leave this part out until there is, and leave the cost benefit up to implementors. A shorter spec is generally one that fewer people can object to, and more likely to be published.

[melvincarvalho]

Generally I think just put this out of scope and let this happen organically. If there's a benefit to doing so, receivers will add it. If the benefits become self evident, then put it into the spec v2.0 or LDP Next, or AS3.0. Happy to be persuaded otherwise.

[rhiaro]

http://www.w3.org/ns/activitypub Yet it doesnt lead anywhere.

They have an open issue for that. I've volunteered to make sure the human and machine readable data that goes up for AP terms is good.

• Here is an existing REC, or very likely to become an existing REC.

That is apparent from AP and AS2's statuses as a WD on Rec-track in the WG.

• This has or is likely to achieve a useful amount of adoption.

Activity from the existing pump.io community suggests there's some chance of this.

• Interoperability would help the LDN add to implementations

At this point, LDN and AP have similar chances of being adopted by their respective communities. Both being compatible with each other increases awareness and likelihood of broader adoption for both, and increases the data available in both ecosystems.

A shorter spec

I'm not sure length is an argument against this one-sentence addition at this point.

[melvincarvalho]

I would be quite happy to adopt LDN.

There are many Linked Data mime types that could be promoted other than JSON-LD and and Turtle (I would suggest there's a few in the W3C that are already RECs or Notes). Unless there's a compelling reason to choose one over another, as an implementor I would prefer editors not to make recommendations here.

Activity from the existing pump.io community suggests there's some chance of this.

This could be a compelling reason. But 'some chance of this' is I think not enough at this point. Anyone else committed to implementing this spec?

[csarven]

Receivers should treat the application/activity+json media type as equivalent to application/ld+json; profile="http://www.w3.org/ns/activitystreams".

This is intended to apply the robustness principle. It is not 'promoting' in my opinion.

If AS2 doen't make it to Rec, I suppose AP might drop it and so will LDN. If AP doesn't make it to Rec, there is less grounds for LDN to mention the equivalence. If LDN doesn't make it to Rec... :)

[melvincarvalho]

@csarven that makes sense, agree to drop it in the cases you outline.

AS2 should include the @context. It should also use the correct mime type. I think these are compatibility breaking bugs that dont have any good justification.

Given that fixing this requires code changes, which I suspect are going to be non trivial to test, I dont understand why this serialization has been prioritized over existing RECs or Notes (e.g. RDF/JSON, RDF/XML, RDFa) which are part of the linked data eco system. Hence my use of the term 'promote'.

[akuckartz]

For the moment I am OK with SHOULD. But it might make sense to mark that as "at risk".

[rhiaro]

Okie dokie, I've updated to explicitly call out that this recommendation is for AS2 support, and that it is at risk of being moved to SWP.

[RubenVerborgh]

we'd need to allow consumers to request application/activity+json and receivers must treat it the same as ld+json when returning data to AP/S consumers;

As mentioned in my post on public-lod, I strongly recommend against such a specific content type. It goes against everything RDF stands for. If you want clients to Accept something more specific (do you really? it might already be implied by the resource), you can use profiles. The “treating it the same as ld+json” is problematic IMHO.

[akuckartz]

@RubenVerborgh Yes, thanks a lot for your support. A problem is that RDF is opposed by some in the Social Web WG. It has been a continuous struggle.

[RubenVerborgh]

@akuckartz Interesting. That shouldn't be a problem though: the profile URI is also just an identifier. Sending it along does not require clients to play along with the whole RDF thing that is behind it.

[melvincarvalho]

@RubenVerborgh there was massive opposition to this bespoke mime type. But certain factions voted it through anyway, and imho does not reflect WG consensus. I stated this in the minutes during the vote. This has been typical IMHO of the process (and lack thereof) during the WG, leading to proposed specs that lack interop. This whole issue is a reflection of that.

[csarven]

@RubenVerborgh We are not inventing or proposing anything new here. Perhaps you've misunderstood. The idea in this issue is that can we re-use an equivalence (mentioned in AS2.0 Core) so that those that wish to design systems can also accommodate the AS mediatype. Same applies for ActivityPub because they are coming from the other direction; using AS mediatype. With the initiative that they will also work with that equivalence. Net result is that there is some possibility to bridge the "LD world" and the "non-LD world". We all agreed in this thread to mark this as at risk, and see if it would be appropriate for SWP to take it over. Result:

• https://linkedresearch.org/ldn/#sending-activitystreams2-support
• https://linkedresearch.org/ldn/#consuming-activitystreams2-support

[akuckartz]

@csarven The best result would be to get rid of the special AS2 media type in all the specifications. As @RubenVerborgh correctly noted it is not needed anywhere to bridge the two worlds. That fact was ignored by RDF opponents when the AS2 media type and the equivalence statement were discussed and decided. I will try to provide a link to the minutes later.

But for the moment the current resolution of this issue is best.

[akuckartz]

Some material documenting the original AS2 media type discussions:

The main original issue regarding AS2: New media type or application/ld+json plus profile

Wiki page: Media type for AS2

IRC log 2015-11-10: Entries between 18:12:51 and 18:39:54 are relevant here. Take note of the vote / statement by one of the WG chairs at 18:34:21 and 18:35:39 and the false or very misleading factual statements at 18:37:07 and 18:37:08 by two others. When I withdrew my sole objection to the proposal which was finally accepted at 18:38:03 I was not aware of the two factual statements. Otherwise my decision likely would have been different.

[rhiaro]

WG F2F discussion:

My preference: move this At Risk feature to a non-normative appendix which links to SWP.