@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.
Discussion
Replies:
21
@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
@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. 😬
