Desired changes for a future revision of ActivityPub and ActivityStreams

[SorteKanin]

@trwnh

@SorteKanin

How is there more prior knowledge required than when you use JSON-LD compared to plain JSON? I mean in JSON-LD land you still need to know what the term "https://www.w3.org/ns/activitystreams#actor" or "https://www.w3.org/ns/activitystreams#object" means.

I meant that you need to know that shorthand terms like actor mean https://www.w3.org/ns/activitystreams#actor and not http://schema.org/actor.

In my imagined plain JSON version of AP, you would not use keys like “actor” as they are much too general. You’d only use keys that are specific and unique, so that there is no overlap in terms. You don’t need to know that “actor” is a shorthand for some longer term because you would just use the longer term and there would be no confusion. There should be no shorthands or multiple representations of keys at all. Sorry if this wasn’t clear from what I described earlier.

@trwnh

I realize that this is unwanted complexity, and people just want to work directly with foo just like they can work directly with native AS2 vocab. But it’s a necessary disambiguation step to allow “plain JSON” to understand shorthand terms.

So again, my solution here is, don’t use shorthand terms. I don’t want to work with foo! I want to work with https://specific.domain/very/specific/path/foo or foo:f8360cc9-160e-442f-93c2-0e0dd17f8fdd. We should be specific and unique. Even the “base” fields of the spec should be that way. I feel like it’s a mistake that the AS2 vocabulary gets some kind of special treatment in the current system and all other vocabularies/terms/extensions are kind of a second-class citizen.

The “base” of the spec should be on the same level as any other “extension”. There should be a very thin, small specification for how to define terms and maybe some very basic common stuff, but everything else should be built as if it was an extension (or maybe many extensions) to the spec. That (or those) extension(s) would probably be widely-used and well-supported, but it should in theory be replacable without changing the core of the protocol. This should also ensure that implementers really support extensions better than they currently do (there wouldn’t really be much to support in this case though, you’d just use the extensions you understand and ignore everything else). This is not really possible right now as AS2 has a kind of special status and is part of the base of ActivityPub. As far as I understand, you can’t choose to not support AS2 terms?

In my vision of ActivityPub 2.0, you should be able to throw away the “base extensions” and use something else if you prefer. Maybe fewer implementations would understand you but maybe you think your model is better and maybe more implementations would move towards your model over time. I hope that makes sense.