洪 民憙 (Hong Minhee) Apr 24
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.
Show thread洪 民憙 (Hong Minhee) Apr 24
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.
ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

Show thread洪 民憙 (Hong Minhee) Apr 24
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. 😩
Show threadsilverpillApr 24

@hongminhee

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.

[Federation]: `Create(Note)` with a single attachment is dropped because `Helpers::verifyAttachments` still assumes `attachment` is an array (follow-up to #6427) · Issue #6588 · pixelfed/pixelfed

Description PR #6427 made handleCreateActivity accept the JSON-LD 1.1 compact form of to/cc (single value instead of a one-element array). The same compaction rule applies to every set-valued prope...

GitHub
Show threadmariusApr 24

> 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

Activity Vocabulary

Show threadEvan ProdromouApr 24

@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"

Show threadBeady Belle FanchannelApr 24
@evan @mariusor @silverpill @hongminhee I can't wait for us to finally drop jsonld in a living standard
Show threadEvan Prodromou
@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?
Apr 24 at 10:13pmWeb
Show threadBeady Belle FanchannelApr 24
@evan cause most Implementations already treat it as if it was plain JSON with a subset of ActivityPub semantics
Show threadEvan ProdromouApr 24
@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.
Show threadBeady Belle FanchannelApr 24
@evan then what's with all the parsing issues like the ones people are complaining about in this very thread?
Show threadBeady Belle FanchannelApr 24

@evan nobody is in all seriousness implementing the full generality of jsonld, that would be a huge attack vector as far as I understand, given the complexity of context merging, reference resolution etc.

Most languages don't provide full jsonld libraries in their stdlib either

Show threadinfinite love ⴳMay 3
@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.)
Show threadBeady Belle FanchannelMay 3
@trwnh
elinks --dump https://www.w3.org/TR/json-ld/ | wc
14618 54990 674684
JSON-LD 1.1

JSON is a useful data serialization and messaging format. This specification defines JSON-LD 1.1, a JSON-based format to serialize Linked Data. The syntax is designed to easily integrate into deployed systems that already use JSON, and provides a smooth upgrade path from JSON to JSON-LD. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines.

Show threadBeady Belle FanchannelMay 3
@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/
JSON-LD 1.1 Processing Algorithms and API

This specification defines a set of algorithms for programmatic transformations of JSON-LD documents. Restructuring data according to the defined transformations often dramatically simplifies its usage. Furthermore, this document proposes an Application Programming Interface (API) for developers implementing the specified algorithms.

Show threadinfinite love ⴳMay 3
@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.
Show threadinfinite love ⴳMay 3
@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.
Show threadBeady Belle FanchannelMay 3
@trwnh you're not saying anything here really
Show threadBeady Belle FanchannelMay 3
@trwnh I'm saying "this thing is too complex we can skip on it and make it less complex" and you are saying actually I have no clue tbh
Show threadinfinite love ⴳMay 3

@Profpatsch you're pointing to a scapegoat and you can't avoid the complexity of a distributed open world system

if everyone already ignores jsonld then how is it jsonld's fault that people are encountering problems unrelated to jsonld? again, i really hope you are sanitizing your inputs and protecting against confusion attacks.

Show threadBeady Belle FanchannelMay 3
@trwnh fwiw I think "on the wire it's compliant JSONLD" is a bit like saying "this random stream of brackets is compliant perl"
Show threadBeady Belle FanchannelMay 3
@trwnh or "this single integer someone sends to the other side o ly expecting ascii integers is compliant YAML"
Show threadBeady Belle FanchannelMay 3
@trwnh does any receiving side actually do fully compliant context resolution? No probably not. And it would be a huge security risk to do so
Show threadinfinite love ⴳMay 3
@Profpatsch anyone using contexts must preload them ahead-of-time, actually. and if you use exclusively terms defined in AS2, you get the equivalent semantics from the media type (application/activity+json). so it only matters for extensions in the first place, which get ignored if they are not defined (and processing continues without breaking on those ignored extensions)
Show threadinfinite love ⴳMay 3
@Profpatsch if you want to agree on extensions without jsonld, you can -- but then you're not being descriptive at all, and you will have failures if you encounter anyone not agreeing with you and using the same term in a different way. if mastodon uses "featured" as a pinned posts collection on accounts and i use it as a boolean on activities, we simply disagree. but you can't detect that without some way of obtaining term definitions. jsonld expansion is one way. central registries is another.
Show threadinfinite love ⴳMay 3
@Profpatsch but even after that, you still have *everything else to deal with*.
Show threadBeady Belle FanchannelMay 3
@trwnh is this everything else in the room with us
Show threadinfinite love ⴳMay 3
@Profpatsch i sure hope it is! otherwise your software does nothing but pass documents around for the sake of passing documents around. do you render those documents? how? do you perform any actions in response to the information in those documents? do you maintain any state regarding those actions? how do you handle conflicts? and so on and so forth -- all the infrastructure you build on top of info exchange is far more complex and unspecified. that's the true source of compatibility issues.
Show threadBeady Belle FanchannelMay 3
@trwnh false dilemma. There is a perfectly fine solution in vendor prefixes that has been proven to work time and time again
Show threadinfinite love ⴳMay 3
@Profpatsch and how do you know which vendors get which prefixes without a central registry?
Show threadBeady Belle FanchannelMay 4
@trwnh you just take one based on e.g. your application name. if there’s a central document somewhere that defines them, I guess that’s possible but optional.
Show threadinfinite love ⴳMay 3
@Profpatsch if you choose to use jsonld (yes it's optional) then you can describe how to expand or compact documents into knowledge graphs and store them in graph databases. the problem you are describing is in AS2 itself, where {} is a valid document describing an Object with no known properties.
Show threadBeady Belle FanchannelMay 3
@trwnh yes, I think we should simplify AS as well. There's no reason for the extra branch on the object