@silverpill'n> "But ActivityPub is the evolution of Atom/RSS, with JSON instead of XML..."'nNot exactly.
General Discussion
23
Post
3
Autori
1
Visualizzazioni
-
While I'm referring to that ancient Slashdot post, let me surface a comment offering a reason why Dave Winer didn't like RDF and my response.
The point here? Whenever we have something like JSON-LD or RDF XML (or, for that matter, SOAP) we are dealing with what some people (and I among them) will call an over-engineered mess.
In this conceptualization ActivityStreams are capable of supporting nearly ANY use case. But they are over-engineered for 80% of use cases.
@jackwilliambell @silverpill the confounding factor is that activitystreams was defined for the purpose of describing streams of activities. literal "activity streams". this is a very clear application and use case, and was even thought to be the unifying model for all social activity on the web. sure, you can map things into rdf just like you can map *anything* into rdf (and json-ld is a way to map any arbitrary json into flat statements). but activitystreams is not being used for that purpose.
-
@jackwilliambell @silverpill the confounding factor is that activitystreams was defined for the purpose of describing streams of activities. literal "activity streams". this is a very clear application and use case, and was even thought to be the unifying model for all social activity on the web. sure, you can map things into rdf just like you can map *anything* into rdf (and json-ld is a way to map any arbitrary json into flat statements). but activitystreams is not being used for that purpose.
@jackwilliambell @silverpill what ended up happening is that mastodon et al didn't actually care about activities; what they were *really* concerned with was their idea of a "post". you can see this in how basically no one on fedi ever renders a Create activity, they unwrap and discard the activity to get at the Note. this happens with basically every activity over the wire -- softwares like mastodon will take any incoming activity and treat it as a procedure call, then throw away the activity.
-
@jackwilliambell @silverpill what ended up happening is that mastodon et al didn't actually care about activities; what they were *really* concerned with was their idea of a "post". you can see this in how basically no one on fedi ever renders a Create activity, they unwrap and discard the activity to get at the Note. this happens with basically every activity over the wire -- softwares like mastodon will take any incoming activity and treat it as a procedure call, then throw away the activity.
@jackwilliambell @silverpill in this way, mastodon et al use activitypub more like a state synchronization protocol instead of as a publishing protocol. except they don't have measures to ensure consistency, like replayable event logs. they just grab whatever they consider a "post" and transform it and cache it in their database, and update records based on incoming activities without storing those activities.
-
@jackwilliambell @silverpill in practice, fedi uses external vocab anyway without json-ld, they just expect everyone else to have the exact same context instead of actually using the provided context. in other words, they hardcode understanding certain shorthand terms without actually checking if those terms mean what they think they mean. this mostly only works because mastodon is the de facto protocol and reference implementation, and not many people care about publishing activities.
Missing link: JSONfeed seems more suited to my intent, but I'll check out your link.
External vocabulary: RSS 1.0 and Atom Syndication both did this with 'extensions', meaning you whacked together a spec and a reference implementation and other projects either picked it up or they didn't. Namespaced to avoid collisions.
That seems to me to be (a) what you describe, but (b) without the need for JSON-LD or RDF or whatever 'does anything, but makes things hard to grok' design.
-
@jackwilliambell @silverpill in this way, mastodon et al use activitypub more like a state synchronization protocol instead of as a publishing protocol. except they don't have measures to ensure consistency, like replayable event logs. they just grab whatever they consider a "post" and transform it and cache it in their database, and update records based on incoming activities without storing those activities.
You are getting into some of the details about how ActivityPub and ActivityStreams do not actually fit well with how people want to use it. And, thus, got hacked in non-obvious and non-documented ways to work with the actual use cases – which is a major reason why ActivityPub is so hard to implement in a generic way.
I guess what I've been saying is: ActivityPub is great and all, but we need something a lot simpler you can use for the 80% use cases without knowing all that.
-
You are getting into some of the details about how ActivityPub and ActivityStreams do not actually fit well with how people want to use it. And, thus, got hacked in non-obvious and non-documented ways to work with the actual use cases – which is a major reason why ActivityPub is so hard to implement in a generic way.
I guess what I've been saying is: ActivityPub is great and all, but we need something a lot simpler you can use for the 80% use cases without knowing all that.
@jackwilliambell @silverpill i guess what i'm saying is that activitypub is already simple if you use it for what it was intended. but if you implement activitypub as intended, you can't talk to mastodon. the complexity isn't in activitypub, it's in everything mastodon requires to talk to mastodon.
the way atom was used in ostatus was a better fit for mastodon, but the reason mastodon moved from ostatus to activitypub was to have followers-only posts without separate feeds per subscriber.
-
Missing link: JSONfeed seems more suited to my intent, but I'll check out your link.
External vocabulary: RSS 1.0 and Atom Syndication both did this with 'extensions', meaning you whacked together a spec and a reference implementation and other projects either picked it up or they didn't. Namespaced to avoid collisions.
That seems to me to be (a) what you describe, but (b) without the need for JSON-LD or RDF or whatever 'does anything, but makes things hard to grok' design.
@jackwilliambell @silverpill extensions in fedi typically *aren't* namespaced. they would be if people used the json-ld context, but most people ignore the context.
jsonfeed is fine but the real question with any format is, who's actually consuming it? that's what drives adoption more than any quality. for web feeds, atom seems to be the cleanest while still being widely supported. rss is awful: https://nullprogram.com/blog/2013/09/23/
-
@jackwilliambell @silverpill i guess what i'm saying is that activitypub is already simple if you use it for what it was intended. but if you implement activitypub as intended, you can't talk to mastodon. the complexity isn't in activitypub, it's in everything mastodon requires to talk to mastodon.
the way atom was used in ostatus was a better fit for mastodon, but the reason mastodon moved from ostatus to activitypub was to have followers-only posts without separate feeds per subscriber.
That's more background information I didn't have. And I've done quite a bit of research into ActivityPub, before I gave up trying to figure out a way to untangle all the ways extant implementations were using it that didn't match the docs.
So, what about the non-Mastodon (and Mastodon workalike) Fedi implementations? It seems to me they all have some weirdness to them, but have we got to the point Mastodon-compatibility is required to use the Fedi? Has ActivityPub failed?
-
@jackwilliambell @silverpill extensions in fedi typically *aren't* namespaced. they would be if people used the json-ld context, but most people ignore the context.
jsonfeed is fine but the real question with any format is, who's actually consuming it? that's what drives adoption more than any quality. for web feeds, atom seems to be the cleanest while still being widely supported. rss is awful: https://nullprogram.com/blog/2013/09/23/
@jackwilliambell @silverpill i think the "hard to grok" is often misattributed to json-ld and rdf, but those are entirely optional, so that's not the real problem. the real problem is the poor data modeling for anything that isn't an activity. you already identified things like Hashtag not making sense; the lack of sense-making extends to other types like Mention and Link. there's other ambiguities like Collection, which can be both paged and unpaged at the same time. it can be quite messy!
-
@jackwilliambell @silverpill extensions in fedi typically *aren't* namespaced. they would be if people used the json-ld context, but most people ignore the context.
jsonfeed is fine but the real question with any format is, who's actually consuming it? that's what drives adoption more than any quality. for web feeds, atom seems to be the cleanest while still being widely supported. rss is awful: https://nullprogram.com/blog/2013/09/23/
I'd argue what drives adoption is ease of use first; even fitness to a use case comes second to good docs, a clean design, and a comprehensible reference implementation.
JSONfeed seems to be 'Atom in JSON'. Which works for me and the microblogging use cases I am envisioning.
-
That's more background information I didn't have. And I've done quite a bit of research into ActivityPub, before I gave up trying to figure out a way to untangle all the ways extant implementations were using it that didn't match the docs.
So, what about the non-Mastodon (and Mastodon workalike) Fedi implementations? It seems to me they all have some weirdness to them, but have we got to the point Mastodon-compatibility is required to use the Fedi? Has ActivityPub failed?
@jackwilliambell @silverpill idk if activitypub has "failed", but if you want to talk to anyone, you are better suited going to their docs instead of the actual spec. or their codebase.
in practice, the biggest flavours are mastodon and lemmy. there's some overlap, and some other flavours that are more niche (funkwhale). fedi is ruled more by consensus and alignment than by spec.
-
@jackwilliambell @silverpill idk if activitypub has "failed", but if you want to talk to anyone, you are better suited going to their docs instead of the actual spec. or their codebase.
in practice, the biggest flavours are mastodon and lemmy. there's some overlap, and some other flavours that are more niche (funkwhale). fedi is ruled more by consensus and alignment than by spec.
> "fedi is ruled more by consensus and alignment than by spec."
Which is as it should be. Trying to tie everything down to a 'single protocol to rule them all' is both an impossible goal and a barrier to creativity.
But I am concerned that (a) Mastodon uses ActivityPub in a way not intended by the protocol designers and (b) is becoming the standard you have to follow – when the protocol itself isn't being modified to be more 'Mastodon friendly'; for lack of a better term.
-
I'd argue what drives adoption is ease of use first; even fitness to a use case comes second to good docs, a clean design, and a comprehensible reference implementation.
JSONfeed seems to be 'Atom in JSON'. Which works for me and the microblogging use cases I am envisioning.
@jackwilliambell @silverpill i want to believe that good docs and clean design reign supreme, but the reality is that worse is often better. there are so many technologies that are widely used because their value is almost entirely in what consumes them. atom vs rss is the clearest example of this -- atom is far superior, but rss will live on because of iTunes-style podcast indexers. who consumes jsonfeed? not as many as atom or rss. but at least you can publish multiple formats.
-
> "fedi is ruled more by consensus and alignment than by spec."
Which is as it should be. Trying to tie everything down to a 'single protocol to rule them all' is both an impossible goal and a barrier to creativity.
But I am concerned that (a) Mastodon uses ActivityPub in a way not intended by the protocol designers and (b) is becoming the standard you have to follow – when the protocol itself isn't being modified to be more 'Mastodon friendly'; for lack of a better term.
@jackwilliambell @silverpill not entirely as it should be imo -- the problem is equivocation. people using the same terms but with different meanings. the expectation is that you agree ahead-of-time; the reality is that no one actually checks this. it's not about "one protocol to rule them all" but the protocol is undefined in many places and undefined behavior is bad. or people use their own interpretations not exactly matching the official definitions, because to them it's "close enough".
-
@jackwilliambell @silverpill i want to believe that good docs and clean design reign supreme, but the reality is that worse is often better. there are so many technologies that are widely used because their value is almost entirely in what consumes them. atom vs rss is the clearest example of this -- atom is far superior, but rss will live on because of iTunes-style podcast indexers. who consumes jsonfeed? not as many as atom or rss. but at least you can publish multiple formats.
@jackwilliambell @silverpill or as the indieweb people will argue, you should just embed this information in the html which you are likely already publishing, because sidecar formats are bad (single source of truth).
-
@jackwilliambell @silverpill not entirely as it should be imo -- the problem is equivocation. people using the same terms but with different meanings. the expectation is that you agree ahead-of-time; the reality is that no one actually checks this. it's not about "one protocol to rule them all" but the protocol is undefined in many places and undefined behavior is bad. or people use their own interpretations not exactly matching the official definitions, because to them it's "close enough".
@jackwilliambell @silverpill btw for "real activitypub" i actually experimented with this for my own website, a page /activity which represents an outbox. the idea is you'd be able to POST activities to that outbox exactly as described by activitypub. but the missing piece is authentication/authorization. i suppose i could do that with some http middleware or something, but there is no standard for this in activitypub -- just a vague mention that you might want to use oauth.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@jackwilliambell @silverpill btw for "real activitypub" i actually experimented with this for my own website, a page /activity which represents an outbox. the idea is you'd be able to POST activities to that outbox exactly as described by activitypub. but the missing piece is authentication/authorization. i suppose i could do that with some http middleware or something, but there is no standard for this in activitypub -- just a vague mention that you might want to use oauth.
-
@jackwilliambell @silverpill or as the indieweb people will argue, you should just embed this information in the html which you are likely already publishing, because sidecar formats are bad (single source of truth).
-
@jackwilliambell @silverpill not entirely as it should be imo -- the problem is equivocation. people using the same terms but with different meanings. the expectation is that you agree ahead-of-time; the reality is that no one actually checks this. it's not about "one protocol to rule them all" but the protocol is undefined in many places and undefined behavior is bad. or people use their own interpretations not exactly matching the official definitions, because to them it's "close enough".
-
@jackwilliambell @silverpill i want to believe that good docs and clean design reign supreme, but the reality is that worse is often better. there are so many technologies that are widely used because their value is almost entirely in what consumes them. atom vs rss is the clearest example of this -- atom is far superior, but rss will live on because of iTunes-style podcast indexers. who consumes jsonfeed? not as many as atom or rss. but at least you can publish multiple formats.
-
> "fedi is ruled more by consensus and alignment than by spec."
Which is as it should be. Trying to tie everything down to a 'single protocol to rule them all' is both an impossible goal and a barrier to creativity.
But I am concerned that (a) Mastodon uses ActivityPub in a way not intended by the protocol designers and (b) is becoming the standard you have to follow – when the protocol itself isn't being modified to be more 'Mastodon friendly'; for lack of a better term.
-
@jackwilliambell @silverpill idk if activitypub has "failed", but if you want to talk to anyone, you are better suited going to their docs instead of the actual spec. or their codebase.
in practice, the biggest flavours are mastodon and lemmy. there's some overlap, and some other flavours that are more niche (funkwhale). fedi is ruled more by consensus and alignment than by spec.
-
I'd argue what drives adoption is ease of use first; even fitness to a use case comes second to good docs, a clean design, and a comprehensible reference implementation.
JSONfeed seems to be 'Atom in JSON'. Which works for me and the microblogging use cases I am envisioning.
-
@jackwilliambell @silverpill i think the "hard to grok" is often misattributed to json-ld and rdf, but those are entirely optional, so that's not the real problem. the real problem is the poor data modeling for anything that isn't an activity. you already identified things like Hashtag not making sense; the lack of sense-making extends to other types like Mention and Link. there's other ambiguities like Collection, which can be both paged and unpaged at the same time. it can be quite messy!
Post suggeriti
-
Cous cous + @varia + @fediforum'n= FediCousCous ❤️'nMmmmh 😋'n#FediForum #FediCousCous'n(#ActivityPub-flavoured food is tastyyy!
General Discussion
1
-
I thought Mastodon's quote post controls were extensive...these are "boundaries" that can be set in Bonfire for your posts.
General Discussion
2
-
Loops is federating with Mastodon and Pixelfed 🥳'nI'm still doing some tests, and will be pushing the ActivityPub PR shortly ✨'n#loops #activitypub #federation #mastodon #pixelfed
General Discussion
1
-
