I hope more #ActivityPub implementations start properly handling JSON-LD documents in various forms, rather than using ad-hoc approaches like only allowing specific fields to accept both arrays and scalar values.
Post
Replies:
34
@hongminhee so, I've been dealing with this problem a lot with tags.pub.
I have found that many projects are open to issues and patches. Even if I have to downgrade what I'm sending over the wire to the least common denominator, I have some hope that the next people who build to the spec will get better interoperability.
I think having good libraries can make the JSON-LD easier.
@evan Can't agree more.
I think having good libraries can make the JSON-LD easier.
Yeah, that's one of reasons why I started Fedify; it was started from building a type-safe Activity Vocabulary library for TypeScript which lets me free from dealing with all complicated things about JSON-LD and keeping it standard-compliant at a time!
@hongminhee the activitystrea.ms library does a pretty good job of parsing and generating AS2, in a uniform way. It pushes you into better habits, which I appreciate.
My book does bare-JSON parsing in all the major examples; I should probably change it in the next version.
Should we start a page for JSON-LD-based AS2 libraries? I think @cwebber did a good Python one, and there may be others.
@evan @hongminhee yes I think we should!
@evan @hongminhee yes I think we should!
@evan @hongminhee @cwebber could you share a link to that Python one?
Or, just use a proper JSON-LD processor altogether. Of course, there would be a performance penalty. The #ActivityPub spec explicitly allows as:Public or bare Public for public addressing in to/cc, etc., but surprisingly many implementations don't handle this. All of this would actually be solved by using a JSON-LD processor.
@hongminhee It's subtly more messed up than that. AP didn't explicitly allow all 3, but it calls out in a non-normative note that implementers may produce non-canonical serializations.
Right now, as:Public is canonical. Public would be canonical if properties like to/cc/audience were vocab-relative, but they aren't (and shouldn't be). Undefining the as: prefix results in the full URI being canonical.
I think introducing a vocab relative term for visibility could make sense, using Public.
@hongminhee It was never entirely clear why the concept of a Public collection was used with properties used for a delivery mechanism. If you're supposed to special case it and not actually deliver to it, then why not separate it out so you don't have to special case it?
For backwards compatibility, I think it could be acceptable to mistake public objects to actually be private objects. (It would be a problem if private objects were mistaken to be public objects, but that shouldn't happen.)
@hongminhee This is all covered in more depth in https://github.com/w3c/activitypub/issues/404 including examples of vocab-relative terms and examples of undefining the as: prefix.
Honestly, I don't really care what strategy other #ActivityPub implementations follow to comply with the spec. (I solved it in #Fedify by just using a proper JSON-LD processor.) It's just a bit annoying that I always send valid JSON-LD documents, but whenever I encounter an interoperability bug where the other side can't process them, I'm the one who has to send them a patch to fix it. 😩
@hongminhee So, I really appreciate that you are doing this work. I know it's hard, and it feels unrewarding, but it really matters, and it really helps the ecosystem.
Please let me know if I can help out in these efforts.
I hope that all of us in the ActivityPub community take these requests seriously when they come in.
Why don't you fix your software instead?
It sounds like you're referring to this issue:
https://github.com/pixelfed/pixelfed/issues/6588
But in Fediverse, attachment is not supposed to be an object, it's an array.
I don't think you should expect people to comply with your vision of ActivityPub.
@silverpill @hongminhee why do we need this kind of complication? What's wrong with just always expecting an array and simplifying the standard instead?
@silverpill @hongminhee why do we need this kind of complication? What's wrong with just always expecting an array and simplifying the standard instead?
@silverpill @hongminhee single element arrays in JSON-LD go to the element itself, not an array.
> attachment is not supposed to be an object, it's an array.
@silverpill I don't understand how you infer that from this spec: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attachment
@mariusor @silverpill @hongminhee yeah, that's definitely not what the spec says.
"The serialized JSON form of an Activity Streams 2.0 document MUST be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm"
@evan @mariusor @silverpill @hongminhee I can't wait for us to finally drop jsonld in a living standard
@Profpatsch what makes you think that's going to happen? It's unlikely. It would require a massive backwards-incompatible change. Why would we do that to a network that has tens of thousands of nodes, 100+ implementations?
@evan cause most Implementations already treat it as if it was plain JSON with a subset of ActivityPub semantics
@Profpatsch "Most implementations" treat it like it is -- JSON-LD. They might use different kinds of processors for publishing or consuming it, but on the wire, it's compliant JSON-LD, according to the ActivityPub and Activity Streams 2.0 specs.
@evan then what's with all the parsing issues like the ones people are complaining about in this very thread?
@Profpatsch the complaints are about bugs on the consuming side for serializations that are correct on the producing side. consumers are applying arbitrary too-strict schemas that are not part of the AS2 spec. hong was asking for consumers to fix their software, and the response was asking hong to break their software in exactly the same way. (dropping jsonld does nothing and is a complete red herring. actually, using jsonld could avoid the issue, because it doesn't skip the normalization step.)
@trwnh
elinks --dump https://www.w3.org/TR/json-ld/ | wc
14618 54990 674684
@trwnh btw I hope you are following all the algorithms, there’s like 10 and they each have 40–50 steps and three layers of branching: https://www.w3.org/TR/json-ld11-api/
@Profpatsch you don't need to implement all the algorithms yourself, you just need to disambiguate terms and normalize the serialization. this is true regardless of whether you use jsonld or not, because it's an open world system. you can't say any property always has only one value, or is always an array, unless defined that way. and most AS2 properties are not defined with those restrictions. people are effectively using the AS2 terms in ways they are not defined, imposing extra restrictions.
@Profpatsch like, i could say the same thing as you, "i hope you are sanitizing your inputs" or "i hope you are disambiguating your terms" or "i hope you aren't being too strict in what you receive" or so on. that's not much of an argument against jsonld because these are things you need to do even without jsonld.
@hongminhee I ran into things like this with Mastodon. I send valid AP activities but if I don’t encode them in a specific way, Mastodon silently ignores them. Like how it assumes the object of a Create activity must be inline and not a reference, but the actor must be a reference and not inline.
@jamie Yeah, exactly such kind of thing!
@hongminhee forced to do whack-a-mole development. 😬
