Social. People. Solidarity.

The next meeting is next Saturday,
4 PM CET or 10 AM EST or …

We will learn about and debate Fediverse Enhancement Proposals

And there is soooo much more:
If your topic is on the waitlist or if you want to speak up, see and enter Amy's pad

· · Web · 2 · 2 · 0

@sl007 @activitypub @pukkamustard @cj serious question: how to be sure that starting a standardization process will be beneficial (not detrimental) to the ecosystem?

"The goal of a FEP is to improve interoperability and well-being of diverse services, applications and communities [...]" That's a nice claim but the road to hell is paved with good intentions

I mean, 1 thing that doomed #XMPP is the XEP process which slowed development pace while user expectations moved faster. Isn't it too soon?


Speaking as someone from the "doomed" #XMPP camp... standards are great, and they need to evolve over time. But especially with open-source you can never force every project to implement the latest standards overnight. It's *very* hard maintaining a coherent yet diverse open ecosystem. We try our best, and XMPP is still alive with a great community and many active projects and users :)

I really do hope the Fediverse can pull this off successfully.

@sl007 @activitypub @pukkamustard @cj


> standards are great

My point is that we are failing to realize they are actually not and keep falling in the same trap

> overnight

#XMPP is hundreds of XEPs that no client implements fully. XMMP is 20+ yo and I still can't reliably send a file to a contact.

We must accept that working implementations > tons of papers on a website. Working code > unfulfilled promises of interoperability.

We need a paradigm shift or we will, once again, fail

@sl007 @activitypub @pukkamustard @cj

@lutindiscret @mattj @sl007 @activitypub @pukkamustard Please make your comments known on the socialhub, too.

FEP is a grassroots and community thing. No power to force anyone to do anything. Most of it is just to document whats already out there so devs can stop fielding the same basic questions.

The only person who has engaged with FEP in advance of a feature is @Claire, who can say whether the process was slow


> just to document whats already out there

Maybe it should be enforced by adding a rule that state that a proposal should not be submitted before at least 2 implementations (in different languages) already exists? It would make sure the proposed is feasible.

@mattj @sl007 @activitypub @pukkamustard @Claire


I understand why such a thing sound appealing. For similar reasons to yours, I'm opposed to rules like this.

If one impl wants to do something different to meet user needs and they want to document this as a FEP (ex: FEP-8fcf) where it gains some community visibility as opposed to leaving it completely undocumented (or privately documented & not as visible), I want to build that community spirit of R&D&share

Arbitrary bars don't help this.

@mattj @sl007 @activitypub @pukkamustard @Claire


> leaving it completely undocumented (or privately documented & not as visible)

Well, that can't be because source-code availability guarantee that. Code (what it actually does) > Documentation (what it should do).

Maybe FEP should require a executable test suite.

@mattj @sl007 @activitypub @pukkamustard @Claire

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard code can require quite a lot of work to understand if you're not familiar with it, it can have subtle bugs, and using it as a black box can be particularly unhelpful (for instance, Mastodon often doesn't return any meaningful message when something wrong happens, and doesn't log it anywhere either; those are things that i plan to improve, but still)

@Claire Thank you Claire, I was having trouble putting to words the ideas you expressed. I've used "run this executable to prove standards compatibility" workflows before (in professional settings, even) and while nice in theory (I am sympathetic to the "code should be self-documenting" idea) it was personally not a fun experience.

Only thing I'd like to add is that there is no guarantee that ActivityPub software impls are open source.

@lutindiscret @mattj @sl007 @activitypub @pukkamustard


> there is no guarantee that ActivityPub software impls are open source.

Should people making such a software be allowed to take part in the standardization process?

Should the #fediverse allow instances running proprietary software? Shouldn't they be isolated?

@Claire @mattj @sl007 @activitypub @pukkamustard


Firstly, I think you are envisioning FEP to be something larger and more monolithic than it is. When it comes to "standardizing" something to ActivityPub, there is a well known, corporate-accessible W3C process for that.

FEP is just a bunch of folks getting together and saying "let's coordinate a little better without too much red tape".

It could change once the SocialCG gives their input on Saturday (hence, comment on socialhub!)

@Claire @mattj @sl007 @activitypub @pukkamustard


Secondly, there is already partially-closed Fediverse software. Matt's attempting to earn a living with, and I don't think there's a movement to isolate that.

As such, I am not sure of a hard and fast rule about open versus closed software being able to participate in FEP. I personally think it'd be cool to have collaboration that led to an open source impl of a proprietary-originating extension.

@Claire @mattj @sl007 @activitypub @pukkamustard

@cj @lutindiscret I hope I won't derail the discussion, but I think that all the parts that deal with the fediverse in are open source. I don't want to speak for Matt, but I would be annoyed to have my software named as closed when it's not.

@mariusor No worries. I tried "partially closed" but IDK the correct terminology for this case. Feel free to correct me. :)


@cj @sl007 @pukkamustard @mattj @lutindiscret @Claire if they comply the standards then who cares? we don't even ban users that use Windoze. and you're worrying about something much less dangerous ^)


> Should people making such a software be allowed to[…]

No disrespect yet, but it's people like you who ruin projects by being jobsworths.

Just *do* real stuff, gain respect by leading, then one day, perhaps, you might be in a position to ponder what people “should be allowed” to do.

@cj @Claire @mattj @sl007 @activitypub @pukkamustard


If it has bugs, your own software has to be compatible with it too so you have to understand the bugs too. The #Fediverse will work if implementations are compatible with each others, bugs included. Actual code compatibility > Conformity to a spec. Mail clients does that everywhere, you can't expect a mail server / other clients to be correct implementations.

@cj @mattj @sl007 @activitypub @pukkamustard

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard yes, we sometimes implement compatibility workaround for bugs

but not all bugs can be salvageable and not all of them are worth implementing workarounds for

if you have a spec you can actually tell how the buggy implementation should be fixed


> slow

I'm just saying that #XEP166 was proposed in 2005, video chat has not landed in Jabber yet... That's slow. #Fediverse won't succeed if it take +15 years to meet a now basic user expectation

We all want the #Fediverse to succeed but I doubt standardization is part of success and really asking myself if it's a cause of failure for decentralized things to emerge.

#Matrix is gaining traction (by not following the XMPP standard...)

@mattj @sl007 @activitypub @pukkamustard @Claire

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard @Claire


XEP-0166 is implemented in many clients, not used only for video (it is also for file sending for instance), and video chat is a thing in XMPP for a long time.

Matrix is using Jitsi which does video… using XMPP

The thing about XEPs is badly understood by lot of people outside XMPP community. A client doesn't need to implement them all at all.

Standardization is a good thing, and the only sane way to interoperability.


> video chat is a thing in XMPP for a long time.

AFAIK for @dino it's "upcoming" support in Conversations is from last year. Gajim? SàT? The truth is it's not implemented actually, I can't expect my contact to support it right now.

I know that XMPP is used as a backend (even in Whatsapp IIRC) but it doesn't make my XMPP account usable to join.

@cj @mattj @sl007 @activitypub @pukkamustard @Claire


But your original premise is that this is somehow the fault of having standards/extensions for these things. I disagree with that.

Whether you put the standards into a single doc (Matrix) or break them up into composable units (XMPP), there will still be implementations that don't have the resources to implement video calls just because you add it to the standards one day.

Standards are not the problem. They are also not a magic solution.

@Goffi @sl007 @activitypub @pukkamustard @Claire


I'm sorry. I may express myself wrongly. I'm not saying standards are bad.

I'm saying that we should focus on working implementation first. Iterate fast, follow user expectations. Then *maybe* standardize later.

Git is not standardized and it has massive adoption as a decentralized software.

I'm sad for the XMPP failure to overwhelm walled garden messaging. I don't want Matrix and the Fediverse to make the same mistakes.

@Goffi @sl007 @activitypub @pukkamustard @Claire


> Standardization is a good thing, and the only sane way to interoperability

You can repeat it as much as you want, it doesn't make it true. It's not an argument. It's a statement you are sure of and I'm not.

I've repeated this to everyone years ago when I was alone on Jabber and everyone was on MSNMessenger. The truth is people could send files each others and I couldn't (Gajim not compatible with Psi/Gaim/whatever).

@cj @mattj @sl007 @activitypub @pukkamustard @Claire

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard @Claire

I've never said it's an argument, my message was mostly to correct your wrong statements about XEP-0166 and video in XMPP clients.

I've just added at the end that standard are a necessary thing, the same way as you say the opposite. This is obviously my opinion.

I can for sure argue about standards extensively, but frankly I have not the time for that.

I wish Fediverse community goes this way though.


Thank you for your work on XMPP.

Don't take me wrong. I was a strong advocate of Jabber years ago. I donate to Conversation and I'm really looking for what Movim is becoming. I don't know what went wrong but success is not here.

@cj @mattj @sl007 @activitypub @pukkamustard @Claire

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard @Claire

Well IMHO the big difference with something like Matrix is that they have several full time paid people.

In XMPP world, specifically with clients (more servers have a company backing them up), it's really rare.

Daniel can work full time on Conversations, and that's a reason why it's more polished than many other clients.

There have been some bad strategical decisions over time also, but overall the protocol is working fine.


> bad strategical decisions

Can you name a few? I'm really trying to find some lessons we should learn for the future of building ecosystem.

@cj @mattj @sl007 @activitypub @pukkamustard @Claire

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard @Claire


- mobile has been neglected for too long, protocol and client wise (it's now fixed except for iOS which should be fixed this year, but it's late).

- took time to integrate changes in UI/UX expectation

- some libraries for easy integration, notably on web, should have been pushed more. People think that it's difficult to use XMPP, while it's not

- Pubsub has been and is still neglected IMO (the potential is not used)

@lutindiscret @Goffi @cj @mattj @sl007 @activitypub @pukkamustard but the fediverse is already made of a bunch of different implementations

so far we haven't strayed too far from the original spec, but there are extensions here and there, and those extensions as well as the activitypub spec being too vague or generic is a cause for incompatibilities

resolving those incompatibilities does require communication between projects, and protocol extension proposals are a natural place to do this


Matrix is making progress by having the same folk developing the standard as are developing the primary implementations (Synapse server and Element client). That automatically makes life a whole lot easier for them.

But if you look beyond Synapse and Element, you'll see plenty of diversity with different Matrix clients not implementing the full specification. That's just an inescapable fact of life in an open ecosystem.

@cj @sl007 @activitypub @pukkamustard @Claire


That's exactly my point. I think Matrix gained a lot of traction by iterating fast, sacrificing the diversity. They gained users this way and freed people from walled garden.

Now the Matrix ecosystem is large and history repeat itself. Too many incompatible clients. Cargo-cult "let's write some RFCs, people love RFCs"... and I fear we are heading to the same destiny. Stagnation in an eternal WIP ecosystem of will-be-working softwares.

@cj @sl007 @activitypub @pukkamustard @Claire


Ok, then I think we are in semi-agreement :)

However the horse has already bolted for the Fediverse. It is already comprised of many implementations, and right now they struggle to interoperate in some areas. That will only get worse.

Standards are a way to guide everyone. Not to magically solve all the problems, but essential unless we want to give up on diversity and have a "Mastodon network" instead (which would be far easier for sure!).

@cj @sl007 @activitypub @pukkamustard @Claire


I'm OK with giving up on some diversity (it's not a goal in itself after all).

I think it's a matter of code > paper. Maybe XMPP failed because the process was spec first, code later. #BitTorrent had a success maybe because it was the other way around.

Documenting a working piece of software is superior to "what's in our mind" spec. So maybe the FEP process should start by acknowledging Mastodon/Pleroma/whatever as a weak reference.

@cj @sl007 @activitypub @pukkamustard @Claire

@lutindiscret @cj @mattj @sl007 @activitypub @pukkamustard @Claire
What other choice? Each dev team implement its own specific protocole to address differently closed yet distinct needs? Do you want to go back to early web with all proprietary extentions and all dirty mess that caused?


> #XMPP is hundreds of XEPs that no client implements fully.

They're not supposed to. That's the whole point of being extensible.

@mattj @sl007 @activitypub @pukkamustard @cj

@cj @sl007 @pukkamustard I have some thoughts about the AP. but they're not put in order and proven with load tests yet. the main problem I see is excessive traffic and absence of subscriptions for tags in the protocol. also serious problems with resources access, when cross-domain authentication is needed.
but traffic problem raises because the end realizations are often lame. developers just don't care what their servers request from the web and how it can be optimized. so I'm not sure changing the standard could solve the issue.
in general, I would look in the direction of more picky subscribes to eliminate the unnecessary data exchange, including users' or relay subscription to selected tags and possibility to ban some tags to avoid getting unwanted content.
but this all needs thorough thinking in depth and running performance tests to prove the effectiveness.
@cj @sl007 @pukkamustard tags can be implemented as collections in ActivityStreams, so it wouldn't need adding extra entities.
Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!