Today we have #ActivityPub, which provides real and actual #Federation, but is overly complex and difficult to implement, and we have ATProto, which promises Federation, but delivers central control and is even more complex and difficult to implement.
-
@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.
-
@jackwilliambell I think it was at https://indieweb.org/microformats , and I think I remember implementing it for Flutterby, though my recent rebuild from circa 2013 backups might have blown that and I may need to re-do it.
@danlyke @jackwilliambell specifically you want https://indieweb.org/h-feed -- which takes its semantics directly from atom
-
This thread is getting long, so I'm going to cut to the chase: I think there needs to be yet another Federation protocol. A simple protocol with a full-featured and generic Reference Implementation.
And I think it should be based on RSS 1.0 or the Atom Syndication spec (except dump XML and use JSON or something):
> http://www.atomenabled.org/developers/syndication/
> https://validator.w3.org/feed/docs/rss1.html
And, finally? I think it should support peer-to-peer Federation.
Let's call it 'Really Simple Federation' – RSF…
[contd]
@jackwilliambell I think you should look into #XMPP. Jabber/XMPP servers tend to be fairly generic. Using XMPP for social media is a bit niche but not without precedent. (See @movim and Libervia)
Yes, there is probably still work to do for what ever you want to do exactly. But at least there is a relatively solid base that you won't get when creating something entirely from scratch.
