Honestly ActivityPub kind of sucks, can we stop cramming every square-shaped use-case into it's triangle-shaped hole please

It is entirely possible AND desirable to make federated protocols without involving ActivityPub

Show thread
@sir But it is still desirable that federated instances talk at least for their basic functionality in a common protocol. And ActivityPub gives us exactly that. Most widely used standardizes protocols are often not the best possible ones and if we go full xkcd 927 we just don't have a federation anymore but many federations.

@naruciakk many federations is *totally fine*. Why should I be able to interact with GitHub via Mastodon? It just doesn't make sense. Why do we have to shoehorn this in

@sir @naruciakk Well in a way, having a way to interact with multiple services through one platform is quite enjoyable.

No need to create a X account, a Y account just to comment or else. ActivityPub is still far from this but it could be something enjoyable.

@lord @naruciakk the fact that it's *kind of* nice in a specific niche situation is not really a good justification for the massive amount of design effort and engineering work that would have to go into shoehorning ActivityPub into everything.

And not having to create an X account to use Y is still feasible when X and Y are different instances of the same protocol Z. Z does not necessarily need to be AcitivtyPub to enjoy this benefit. For example, sourcehut already has this with email - you can participate in sourcehut discussions on tickets, patches, and mailing lists with only an email address, no additional registration of any sort is required.

@sir @lord >For example, sourcehut already has this with email - you can participate in sourcehut discussions on tickets, patches, and mailing lists with only an email address, no additional registration of any sort is required.

Yes, it doesn't have to be ActivityPub, but now it is more of less accepted as a common interface in federated social media and it's managed by W3C which is kinda a nice and tidy situation and far from being the worse option like e.g. having a common standard that is owned by some corporation or shaky non-profit etc.

I haven't seen email (or SMTP) utilized for this specific usage, I've seen email used for creating a decentralized instant messaging and it works… ok at most, but it works nonetheless. I don't think that it would be impossible to create a common protocol based on email, but we have this one which is not bad from the political and management side.

And still, if we want to use email to communicate between instances they still must implement a way to use it in the same way. And if we want just to use email like you use in Sourcehut – for replies etc., basically as a some kind of a user interface and entry point that everyone can use… that's actually a pretty good point and I'd love to see it implemented in various fedi instances. But it won't remove a need for a common interface (which ActivityPub does acceptably well) between the instances, because this is what truly allows me to reply from the Pleroma instance I use to you and have this message nicely transmitted to your Mastodon instance (or Honk or whatever else).

@lanodan
>It's like modern HTML5 in a way.

But deep down – well, HTML5 is the backbone that works everywhere. I don't really care what every instance do by itself if I can read it in my instance using this common language.

@naruciakk @sir @lord @lanodan
even if APub is not bad from the political and management side (which I doubt), it's bad from the technical and documentation side.
It has only existed for like 5 years and it's already more of a mess than IRC.

As for sourcehut - it doesn't use email as a UI. It uses email to federate. For example, you can send a patchset from one git.sr.ht repo to a mailing list on some other sr.ht instance using the web UI.

@wolf480pl @naruciakk @sir @lord IRC is pretty much dead so of course it seems less of a mess than most things out there as kind of everything is documented and well-known.

@lanodan @naruciakk @wolf480pl @lord "IRC is pretty much dead"

- lanodan, literally 90 seconds after her last IRC message, and 36 messages prior to her next one

@sir @naruciakk @wolf480pl @lord As something that people work on, see how slow and not-so-working IRCv3 goes.
Follow

@lanodan @sir @naruciakk @lord

Maybe the authors just appreciate that changes in protocol should be given some time?

I despise the move-fast-and-break-things mentality. Changing quickly isn't a sign of being alive, it's a sign of bad project management.

· · Web · 3 · 3 · 5

@lanodan @sir @naruciakk @lord
*changing quickly is a sign of immaturity.
Changing quickly forever is a sign of bad project management

@wolf480pl @lanodan @sir @naruciakk @lord you could always just do the old CLisp move.

"everybody do shit that kinda works with enough tape."
[4 years later]
"ok we just broomed up all the things everyone did and wrote it down as the spec."
@wolf480pl @sir @naruciakk @lord Sure, things should be given time but IRCv3 takes a very long time to get anything done on the software side and even then a lot of clients don't implement the new things, not to even mention the servers. (Would be surprised if freenode has any IRCv3 thing)

@lanodan @sir @naruciakk @lord
CAP LS reply on freenode.net:

account-notify away-notify cap-notify chghost extended-join identify-msg multi-prefix sasl tls

@lanodan @lord @naruciakk @sir @wolf480pl so "i want to help out by writing an irc3 server" is a meaningless statement.

@icedquinn @sir @naruciakk @lord @lanodan
No.
It would be more helpful to say "I want to help out by writing an IRCv3.2 server" or "by writing an IRC server with all IRCv3.2 extensions, including the optional ones", but to me it seems like if you implement some of the IRCv3 extensions, the rest comes naturally

@icedquinn @lord @naruciakk @sir @wolf480pl If your software can only be described with one thing it probably is. (See most of the rust reimplementations in the years to come)

@icedquinn @sir @naruciakk @lord @lanodan
no, it's a framework for making IRC extensions, a set of extension specs, and a series of reqeuirement levels on which extensions you should support in $CURRENT_YEAR

@lanodan @kline @lord @naruciakk @sir @wolf480pl Odd, that comment didn't appear in the thread on my instance yet. My apologies.

@tyil @kline @sir @naruciakk @lord @lanodan
Yeah it's easy to get bitten by this.
Best to always open a permalink to the post you're replying to and check the replies on its instance of origin, but I don't usually do that myself so yeah...

@tyil @naruciakk @wolf480pl @lord @lanodan freenode supports a lot of IRCv3, but supporting all of IRCv3 isn't an achievement.

There are some things in IRCv3 we will specifically not support and that doesn't mean that freenode is bad, or behind the times, it just means there are some things that don't actually improve the freenode experience.

Having typing notifications doesn't make sense in most freenode channels, for example.

IRCv3 support isn't a highscore table.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!