Social. People. Solidarity.
The next meeting is next Saturday,
4 PM CET or 10 AM EST or …
And there is soooo much more:
If your topic is on the waitlist or if you want to speak up, see
https://socialhub.activitypub.rocks/t/upcoming-socialcg-meetings/1257 and enter Amy's pad
"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.
> standards are great
My point is that we are failing to realize they are actually not and keep falling in the same trap
#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
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.
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.
> 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.
@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.
> 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?
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!)
Secondly, there is already partially-closed Fediverse software. Matt's attempting to earn a living with Write.as, 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.
> 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.
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.
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...)
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" https://fosstodon.org/@dino/104671894466537578 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.
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.
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.
> 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).
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.
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.
- 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)
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.
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.
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!).
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.
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!