@elchapo off you go

@TheHottestPotato the ActivityPub specification defines server to server communication as well as server to client communication. without the clients to create the activities, nothing would be federating. the two elements are both necessary in order for AP to work.

the AP specification does stop short of providing for the things that mastodon's api provides for. however, to me, it would make more sense to modify the specification than splintering the fediverse

@scarly oh I know that it defines a client/server communication, that was what I was talking about in the second paragraph.

I just do feel like its a bit inaccurate to say that the client-server communication and toolchain is part of federation. It does make the ecosystem more painful when its not consistent though I will absolutely give you that. I dont think there are any (usable) pure AP clients that exist?

@TheHottestPotato you can't have a usable pure AP client because AP doesn't define a large part of what you need to make software usable

interfaces for posting, moderation, etc - these require an api. you seem to be suggesting that this is not part of federation. pedantically speaking, sure, but realistically speaking - the simple act of pushing messages between servers is useless without an interface for people to manipulate those messages in meaningful ways

@scarly @TheHottestPotato I'd argue the situation you're describing with Mastodon/AP is exactly how email, the first successful federation system, operates. Every mail user agent has to make up its own bespoke APIs in order to compose, mark things as spam etc. The basic protocols for transmission (SMTP) and storage (IMAP) allow everything to work, but literally every client has to re-invent the wheel for everything else.

@drzaiusx11 @TheHottestPotato analogies aren't the best way to talk about this, but ill bite.

an email client is not the same thing as the api for an instance of mastodon. what you're talking about is more on the level of Tootdon or Toot! than it is on the level of mastodon. we're talking about different levels of abstraction.

@drzaiusx11 @TheHottestPotato
if thunderbird suddenly changes how it works, then that affects thunderbird users. if mastodon changes its api, then that affects other instance servers that are mastodon compatible, all mastodon tools, all proprietary and non proprietary apps. there are a ton of side effects in this scenario that create work downstream and can cause a loss of interoperability.

it's disengenious to suggest that an API is the same as an email client.

@scarly @TheHottestPotato Agreed that the analogy breaks down for older standalone email clients, but is still applicable w.r.t. webmail.

SMTP+IMAP is AP. With webmail if you want to write an email you need an API to another server for that. That's a bespoke api specific to the webmail client. Thats like mastodon.

@scarly @TheHottestPotato The difference with mastodon is that its all one big server instance whereas in email this is usually broken up by protocol: Sendmail for SMTP, Dovecot for IMAP, some bespoke API server for your webmail (squirrelmail server etc)

@scarly @TheHottestPotato its not disingenuous, this is the exact scenario for webmail.

Mastodon is an API server with a web client. Gmail has its own API, if you want to make a new Gmail front-end you're at the mercy of them changing things on you. Same with squirrel mail, roundcube or rainloop.

I'm not saying its ideal or even a good situation, but its exactly how things have worked in the realm of federated software for 50+ years (in the case of email.)

@nutomic except that the developers of other projects are trying to work together, but the addendum to what gargron said is that the api documentation is not going to speak to interoperability.

i'm sorry but that definitely is something that mastodon is at fault for, because it's within gargron's power to maintain a healthy ecosystem for the fediverse. app developers will likely not try to implement multiple apis

if mastodon is exclusionary then that's a problem

@scarly The way I read it, Gargron is talking about the current state of things (ie "API was never intended to be ..."). I think that could be changed, or new documentation could be written for a cross-project API. But that would need more effort than just trying to copy the API.

@scarly I also love the blanket statement that Pleroma users are rude and unhelpful. Gagron is so much hit and miss for me.

@Tamber @scarly the problem is that a social network requires popularity for it to actually perform its job, otherwise the "all my friends are on X" is too strong to retain users. This implies someone or a group of people get to have some control over such popularity. To get everyone on board with a social network revolt to wrest control back to the people you kind of need control of that popularity in the first place.

@Tamber @scarly bah I'm going to start rambling if I keep this up. In short, open source communities in-fight worse than the UN.

@jaz @Gargron hey, do me a favor? please shove off. there's a huge difference between entertainment, pleroma, and pig farming. i assume that you can figure that out?

@scarly @jaz @Gargron man, dudes just can't stay the fuck away from this thread, can they? 🤷

@Chel @scarly @jaz I like how he tagged Gargron like he was going to tattle on us or something.

@Chel @scarly Please stop tagging me, thanks!

@Gargron as a practical observation, you could have simply muted this conversation and moved on

it was not me that tagged you originally. i assume that you know this because you did remove the reply guy from your backhanded slap.

if you don't want to be tagged when the reply guys come after me then tell them that. do you understand? thanks!

@jaz @scarly this incredibly condescending reply embodies the sort of mentality that holds open source communities back.