> while linked data cultists harass developers about nonresolvable URLs
Technical Discussion
12
Posts
4
Posters
0
Views
-
> while linked data cultists harass developers about nonresolvable URLs
@silverpill I don't consider myself a cultist but I still think that putting invalid URLs in any payload where they are supposed to be meaningful is disrespectful towards anyone that consumes your API. Please don't do that.
-
> while linked data cultists harass developers about nonresolvable URLs
@silverpill I don't consider myself a cultist but I still think that putting invalid URLs in any payload where they are supposed to be meaningful is disrespectful towards anyone that consumes your API. Please don't do that.
@mariusor @hongminhee The
@contextis not supposed to be required in the first place, but here we are adding it to every activity and wasting bandwidth because Mastodon developers didn't read the spec. -
@mariusor @hongminhee The
@contextis not supposed to be required in the first place, but here we are adding it to every activity and wasting bandwidth because Mastodon developers didn't read the spec.@silverpill I'm sorry, I'm not aware of that and I thought I read the specs pretty thoroughly. Could you point me in the right direction for where you got this information from?
-
@silverpill I'm sorry, I'm not aware of that and I thought I read the specs pretty thoroughly. Could you point me in the right direction for where you got this information from?
@contextis a recommendation, not a requirement.ActivityPub:
https://www.w3.org/TR/activitypub/#obj
Implementers SHOULD include the ActivityPub context in their object definitions.
ActivityStreams:
https://www.w3.org/TR/activitystreams-core/#jsonld
Implementations producing Activity Streams 2.0 documents SHOULD include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams".
-
@contextis a recommendation, not a requirement.ActivityPub:
https://www.w3.org/TR/activitypub/#obj
Implementers SHOULD include the ActivityPub context in their object definitions.
ActivityStreams:
https://www.w3.org/TR/activitystreams-core/#jsonld
Implementations producing Activity Streams 2.0 documents SHOULD include a @context property with a value that includes a reference to the normative Activity Streams 2.0 JSON-LD @context definition using the URL " https://www.w3.org/ns/activitystreams".
@silverpill aaah, I see. I think we've had this discussion before (or at least I had it with someone else).
For me "SHOULD" falls in the category of the robustness principle: "be conservative in what you do, be liberal in what you accept from others".
So for me if you treat "SHOULD" in a spec as non mandatory you haven't really implemented the spec.
-
@silverpill aaah, I see. I think we've had this discussion before (or at least I had it with someone else).
For me "SHOULD" falls in the category of the robustness principle: "be conservative in what you do, be liberal in what you accept from others".
So for me if you treat "SHOULD" in a spec as non mandatory you haven't really implemented the spec.
@mariusor I don't remember having such discussion. The SHOULD keyword is defined in RFC-2119:
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
There are many valid reasons to not include
@context. We also have almost 10 years of implementation experience and by now full implications are very well understood: by ignoring this recommendation we make messages smaller and developer experience better. No downside at all. -
@mariusor I don't remember having such discussion. The SHOULD keyword is defined in RFC-2119:
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
There are many valid reasons to not include
@context. We also have almost 10 years of implementation experience and by now full implications are very well understood: by ignoring this recommendation we make messages smaller and developer experience better. No downside at all.@silverpill@mitra.social @mariusor@metalhead.club But if you omit
@context, wouldn't it fail to work correctly in some implementations that rely on a JSON-LD processor? Fedify is actually one of those cases. -
@mariusor I don't remember having such discussion. The SHOULD keyword is defined in RFC-2119:
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
There are many valid reasons to not include
@context. We also have almost 10 years of implementation experience and by now full implications are very well understood: by ignoring this recommendation we make messages smaller and developer experience better. No downside at all.@silverpill regarding size, ActivityPub is such a verbose protocol that the hundred or so of raw bytes you save through omitting context, are most likely negligible through the prism of connection compression. So to me that's not entirely a "valid reason".
And as developer myself, I think that contexts, even in a non valid JSON-LD implementation, offer enough guidance for building a data vocabulary for them to have plenty of value.
Do you propose we replace contexts with Open API specifications, or how do we coordinate what's a valid vocabulary data object in a federated network? And how do you propose that others discover these specs?
-
@hongminhee can you point me to the parser you use for fedify?
One of my long term plans for GoActivityPub is to built a code generation tool based on contexts and I would need some prior art to see what's important in parsing JSON-LD and RDF.
-
@silverpill regarding size, ActivityPub is such a verbose protocol that the hundred or so of raw bytes you save through omitting context, are most likely negligible through the prism of connection compression. So to me that's not entirely a "valid reason".
And as developer myself, I think that contexts, even in a non valid JSON-LD implementation, offer enough guidance for building a data vocabulary for them to have plenty of value.
Do you propose we replace contexts with Open API specifications, or how do we coordinate what's a valid vocabulary data object in a federated network? And how do you propose that others discover these specs?
@silverpill personally I feel like the various activity/object signing methods that get used in recent FEPs are more egregious from a size point of view, when the in spec behaviour for obtaining canonical versions of a resource is to fetch them from their server, instead of relying on random object signing that introduces so much more friction.
-
@silverpill personally I feel like the various activity/object signing methods that get used in recent FEPs are more egregious from a size point of view, when the in spec behaviour for obtaining canonical versions of a resource is to fetch them from their server, instead of relying on random object signing that introduces so much more friction.
@mariusor@metalhead.club I thought the whole point of signing objects or attaching proofs (none of which I do, mind you) are precisely to save the need to make a new request, which comes with its own overhead.
The good thing is fetching from canonical source will never go out of style.
Aside, it seems like I'm only getting Marius's posts, not silverpills. Makes for an interesting one-sided exchange 😛
-
@hongminhee can you point me to the parser you use for fedify?
One of my long term plans for GoActivityPub is to built a code generation tool based on contexts and I would need some prior art to see what's important in parsing JSON-LD and RDF.
@mariusor@metalhead.club It's barely documented, but has worked well so far!
https://github.com/fedify-dev/fedify/tree/main/packages/vocab-tools
-
System moved this topic from Uncategorized
Gli ultimi otto messaggi ricevuti dalla Federazione
-
"Bob's followers" is the literalist version, with the worst possible dynamics. "You should reply to a followers-only post with a followers-only post" retains the same UI choice while completely changing the audience. Most of the other people who read Alice's post won't see Bob's comments. Bob's followers who don't follow Alice won't understand the context of his post, and won't be able to read Alice's post.
-
"Alice's followers" is the way most social networks work with private X, Facebook, Instagram. It lets Alice ask questions or share private info with people she trusts and cares about, and lets them discuss amongst themselves. It is really the best way to use social networks.
-
Hey, all. So, I appreciate the responses. I'll break down the options here.
-
@julian@fietkau.social yes you are correct as far as my limited understanding goes.
My personal definition of side effect limited to "unintended consequences", which differs greatly from the ActivityStreams definition, so for my own sanity I avoid the term in my own documents 🙂
-
@julian I think so, to me that sounds entirely correct, or at least I would understand what you mean. :)
-
@mariusor I think I get it, yeah. Would that still fit with my draft definition? It feels weird to call it a side effect when a `Like` towards an object gets added to its `likes` collection, since that's arguably part of the intended effect. But that's what I'm picking up from the standard as well: https://www.w3.org/TR/activitypub/#likes
-
@julian I use side-effect a lot when talking about ActivityPub activities and I mean it close in context to its functional programming meaning, where an action can have side-effects which are not immediately observable from its input or output.
Ie, when a Create activity determines a server to persist an object to disk that's a side-effect of the Create. When an Undo activity removes its object activity from disk, that's another side-effect. They are not immediately observable from the results of the Activity upon its server or its client.
Does that make sense?
-
FEP drafting: Am I using “side effects” here the same way as other ActivityPub developers? I've seen the term used a bunch in casual conversation, but my personal understanding of it is kinda fuzzy.
