a world where applications are spec-driven (or protocol-driven) sounds like a nice place to live, unfortunately i don’t think it works in reality. even if i look at the examples of spec-driven platforms provided by the article, many of those i consider failed:
email: that thing is mostly broken, because of spam, and when email providers try to limit spam, they have to employ heuristics, which in turn cause problems for smaller email providers (this is even mentioned in the article). no usable encryption too. i think people don’t use email much for communication anymore. for example, in my personal case, most of the communication with friends & family happens through instant-messaging-platforms. my email is for proving my identity when signing up for services, receiving newsletters, talking on mailing lists and getting job offers. so yeah, maybe the last two can be considered communication. but i think you get the point.
xmpp: xmpp failed for me even without google closing down google-talk. my problem with xmpp was ironically their protocol being extensible ( https://xmpp.org/extensions/ ). (mind you, my experiences are from like 5 years ago, maybe today all this is fixed) this means, you can have an xmpp-client that considers themselves an xmpp-client but it does not support for example file-transfer, or video-calls. in theory we can see a certain beauty there, see, you can create a minimalistic client that can transmit messages through xmpp. on the other hand, this is useless for non-technical users. so, you while you can say that xmpp has many many clients and servers, and that xmpp has many many features, those two are not true at the same time. of course, one approach is to have one well working and well supported reference implementation that does all that is needed, and when talking about xmpp one can point users to that specific implementation…. i think you see where i am going here :-)
common lisp: the common-lisp standard is from 1994. there is no newer standard. iirc, it does not have sockets for example. so, to write common-lisp applications, you will learn the standard library of the given specific common lisp implementation.
i’m trying to think about applications meant for non-technical users, where the is a “spec” rather than an app. web-browsers are such a thing i guess? and even there, we only have 2 (or 3,depending how you count) “real” implementations.
you can have an xmpp-client that considers themselves an xmpp-client but it does not support for example file-transfer, or video-calls
It was (is?) so much worse than that. You could have two clients that implemented file transfer and video calls, but using different extensions and so they couldn’t interop.
One of the big problems here is that most users do not know the difference between a protocol, service, service provider, and app. They see Hotmail or Gmail or WhatsApp as monolithic things. They use the client provided by the service and they see the client, service, and service provider as a single monolithic entity. A few may sometimes use an additional client, but often don’t realise that they’re still using the same service when they do.
Signal gave up on trying to educate users here. The Signal service, protocol, and app are all presented as a uniform blob. I suspect that this is the biggest reason why Signal is the most successful open messaging platform.
…but often don’t realise that they’re still using the same service when they do.
And somehow it goes even further! Just the other day a friend told me that her mother got a new Facebook account because she got a new phone and thought her Facebook account was linked inextricably to the physical device she used to access it. I also have heard a number of anecdotes where people sign up for a new Gmail account each time they get a new Android phone.
If people want federation and open protocols to succeed they should stop writing new software and specs and start working out how to explain the whole idea to users and make them care about it.
The Fediverse: not as mainstream as social media giants, but still a thriving community with millions of users
Fediverse is barely a spec. Mastodon only implemented the S2S portion of the ActivityPub spec and even then only a subset of it. Mastodon still uses a bespoke API to talk to its clients and the client/server situation is a mess. The only 3 well-supported S2S implementations I know are Mastodon, Pleroma, and honk. I don’t even want to get into all the issues with ActivityPub.
You are absolutely correct. I considered including Mastodon as an example of an implementation with too many idiosyncratic features, but I don’t know enough about it. Maybe you could make a blogpost in response!
BitTorrent was originally the name of both the protocol and the client. Later people used the same protocol to build other clients, but the original model wasn’t too different from e.g. Signal. This is probably a major reason for its success. If it had used the “XMPP model” of just publishing a specification (or a specification with a client as an afterthought) then it probably never would have become as popular as it did.
The same more or less applies to the web: Berners-Lee didn’t just publish a bunch of specifications, he published a HTTP server, web browser, and web editor. And the web’s later mainstream growth was driven by products (Netscape and IE mainly) rather than specifications.
To be fair, Jabber was the protocol of a reference implementation with corporate backing first, then the IETF spec came later. That was just so long ago in internet years that it’s barely relvant anymore
Neither were ever a “closed” platform; it’s just the difference in focus/communication:
Publish an open protocol, market/communicate the protocol, and wait for people to write clients for it.
Publish and open protocol and write a good (or at least decent) open implementation of it, and mainly advertise the implementation rather than the protocol.
common lisp: the common-lisp standard is from 1994. there is no newer standard. iirc, it does not have sockets for example. so, to write common-lisp applications, you will learn the standard library of the given specific common lisp implementation.
Not necessarily, take the example of sockets. As the language is extensible, a library can abstract over implementations extending the language. The same applies to threads, for example. Then all other libraries depend on these projects, instead of implementations.
Let’s not forget IRC, where implementing a server is almost not-possible by just reading the RFCs. Everyone likes to talk about how easy it is to implement a client, but a server is a whole other can of worms.
This is a less philosophical and more actionable follow-up to my previous article, “Whatsapp and the domestication of users”. Unlike the previous article, this one focuses on more technical solutions: spec-driven development and implementation diversity.
I haven’t seen very many good arguments against what Moxie has said with regards to competing on features. Comparing this with countries - even in a representative democracy like the United States, our military is a strict hierarchy. This is despite the democratic principles of the country. The reason? There is an evolutionary pressure on militaries to find the most competitive structure - those who have tried other things (as Orwell talks about in revolutionary Catalonia) failed in part due to the structure they adopted. Moxie has noticed the loss of open source projects to these closed companies due to their insistence on a more virtuous structure and has decided that the perfect is the enemy of the good. To me this seems analogous to the arguments between pure utopian anarchists and more pragmatic people (considering Moxie’s political orientation he is probably intimately aware about the tradeoffs here).
Since reading Moxie’s polemic against federation (I assume you’re talking about the “Ecosystem is Moving” essay, though Moxie has repeated the idea elsewhere), I’ve slowly come to the understanding that the only way to win this competition on features is to not play at all. After all, there’s almost always someone out there with more money/determination than you, which I guess is especially true in terms of open/community-owned projects vs. more commercial endeavors.
Part of what I’ve come to dislike about these more boxed platforms (to borrow a term from the linked article) is how they’ve made online discussions more ephemeral, both in terms of owning one’s archive, and in terms of being able to stay part of a community regardless of which device/system I happen to be participating from. For most of these platforms, clients running on “legacy” systems (be it older devices or devices on non-mainstream operating systems) are routinely dropped or not developed for in the first place; some platforms place constraints on participating over multiple/alternative devices, such as a mobile device and a desktop device (ostensibly because of E2EE concerns).
This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.
Conversely, platforms such as IRC and XMPP continue to be useful even on ancient or under-powered devices, albeit in a perhaps degraded capacity, and allow for the sort of mixing-and-matching of use-cases made harder by their boxed counterparts. This, to me, is a more user-friendly and inclusive approach to building communication tools; unfortunately, being more inclusive means taking the foot off the pedal, or at least taking a more mindful approach in rolling out features.
This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.
Communication (like most human endeavors) is constantly changing. Language changes, communication methods change, speakers change (including marginalized groups into conversations), and expectations around media change. This isn’t “progress” in the Baconian sense but it is change. IRC and XMPP (along with their technical issues which others in this thread have covered in great detail) just hasn’t been able to keep up with changing expectations of communication. Realistically, the general population sends pictures of computer monitors to their friends over Snapchat. Sticking to IRC just codifies a different set of social norms into place.
Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.
Featuritis causes these changes more often than change causes featuritis. Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.
Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.
You’re taking too short of a view of this. Humanity used to send smoke signals and use oral storytelling to communicate. In the meantime, we seem to have invented writing, paper, printing presses, newspapers, telegraphs, radios, and all sorts of other manners of communication. Whenever I see folks say things like change is driven by featuritis, I invite folks to tell me where they draw the line between essential change and featuritis change and to justify why this line is valid.
Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.
Right but what about folks that are hard of sight? Folks that are dyslexic? People that comprehend things through image better than text? Traditionally these folks have been excluded from the conversation. In fact, the history of communication has largely followed the democratization of communication to new actors. Why is plaintext encodable written language the point at which we must draw our line in the sand?
EDIT: I also want to point out that there are people that enjoy change. They enjoy learning new slang, they love participating in new memes, trends, conversations, and ideas. This isn’t to say that new is inherently better, but nor is it to say that new is inherently worse. But there is a contingent of people out there that legitimately enjoy change. If you want to include folks in the conversation (which is the whole point of creating open communication platforms, right, to enable humanity to communicate), you need to account for folks that will change their colored contacts on a whim as much as the person who is fine using their 20 year old laptop to view plain text.
Right but what about folks that are hard of sight? Folks that are dyslexic?
Dictation does not require creating a new protocol; that’s a client-side feature.
Why is plaintext encodable written language the point at which we must draw our line in the sand?
Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.
there are people that enjoy change
Client-side change is fine as long as that change doesn’t devolve into a boxed platform. Nobody’s stopping you from switching out themes or clients when you feel like it.
Dictation does not require creating a new protocol; that’s a client-side feature.
What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity? What about folks that are blind and deaf, or who don’t know a certain language?
Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.
Citation needed. We communicated without written language for a very long time. Why do we need to use written language now? How is it the minimum of anything? We don’t even have a universal theory of human semantic processing, so how can we prove that written communication is the minimum?
But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer? Why is the implementer more important than the user? Why is an open protocol more important than the act of communication itself? When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.
This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality. If you want to communicate with your fellow FOSS-natives on Freenode and grumble about the kids on TikTok be my guest, but others will not be willing to make that choice. If FOSS actually wants to enable end users and not technical FOSS-natives, then FOSS needs to prioritize users just as much if not more than its principles. In the meantime, others will explore other tradeoffs. Like Moxie with Signal, Element with Matrix, and Gragon with Mastodon. I can tell you that IRC hasn’t changed much and FreeNode hasn’t gone anywhere in the last several decades, yet the mindshare has very much moved away from FreeNode, and that’s because users have put their “money” (or time or effort or whatever) where their mouth is and have voted with their feet.
For me a good metric of success with a communication protocol/product will be when you observe average teenagers in the developed and developing world organically using your product to communicate. They use things like Instagram and WhatsApp but they probably don’t use IRC. I did use IRC when I was a teenager, but there were fewer options then and IRC mirrored the cultural context of online communications at the time much more than IRC does now. I think you’d be hardpressed to get any teenager these days to use IRC.
What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity?
Use the right tool for the job. A VOIP protocol would work well for sending voice. You could make a meta-client that combines a VOIP client and an instant-messaging client if you want to do both at the same time. There are better ways to do this than making the protocol more complex.
What about folks that are blind and deaf, or who don’t know a certain language…why do we need to use written language now?
People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.
But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer?
Yes. I explained my rationale for simplicity in the previous post, Whatsapp and the domestication of users. When complexity grows past a certain point, implementers need to spend more working-hours and need more funds to create a viable implementation; requiring too much funding can encourage dark patterns and conflicts of interests (e.g., investor money). I’d recommend checking out the article if you’re interested in this topic.
Why is an open protocol more important than the act of communication itself?
Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.
When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.
Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.
This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality.
Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used).
In the meantime, others will explore other tradeoffs. Like Moxie with Signal
I’ve explained why I find Signal problematic in the previous post. I don’t think one org should own a communication platform.
I think you’d be hardpressed to get any teenager these days to use IRC.
I was a teen on IRC until last year when I turned 20. There are dozens of us!
Also, a quote from this article:
I’m not arguing that average users are doing something “wrong” by doing otherwise; expecting average users to change their behavior for the greater good is naive. This advice is targeted at the subset of users technical and willing enough to put some thought into the platforms they choose, and indirectly targeted towards the people they can influence.
I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.
People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.
Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about. If anything, that sounds like prioritizing the freedom of the able over the freedom of anyone else.
Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.
For me communication is not worth gimping for the sake of being minimal or implementation-friendly. I am fine accepting complexity in client, protocol, and server to enable users to communicate in novel, ergonomic ways. Communication is much more important to me than implementer ease. I’ll go further and say, given a choice between implementer ease and rich communication, almost everyone would pick rich communication. Only a minority will be so motivated by the spectre of lock-in that they will reject attempts to broaden the platform.
Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.
This is part of your personal “house spec” of course. I think you’re going to have a really hard time finding everyone agree on a “house spec”, and in practice you see folks with very different types of living domiciles based on their preferences. In college, I had friends who lived without central heating and wore thick jackets to use the bathroom. This was their choice.
Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used).
I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.
For me and many other technologists, technology is primarily about the user and the human component, only secondarily about protocols, implementer ease, ideology, or anything similar. I view technology as slave to the human, not human as slave to the technology. I think you’re going to have a hard time convincing tech users like us otherwise. After all, we’ve had decades of IRC, and even among technologists IRC has lost ground, not gained it. I’m sad to say I don’t think this viewpoint has any bite except among a dedicated few, who will continue to stick to IRC and grumble about new protocols and their freedoms.
“Man is born free, yet he is everywhere in chains”
Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about.
I agree, and this is the reason why I think we should build everything we can from plaintext. Audio excludes the deaf, visual excludes the blind, but plain text includes the largest possible audience. Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.
I view technology as slave to the human, not human as slave to the technology.
Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.
A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses. The benefit of open platforms is that you get that choice without excluding users on low-end devices who can’t afford to run a fancy Electron app. Open platforms are a means to include everyone and serve the human rather than the platform owner. If your use-case isn’t met, you can build an implementation that meets it.
Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.
I just don’t agree, and without studies to back this viewpoint up, I’m going to take this as an ideological viewpoint.
Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.
Indeed, but I think you and I have different definitions of ownership. Simplicity and ease of implementation are not prerequisites for ownership in my mind. That simply passes the buck to the technologists, of which ideally we wouldn’t force the entire population to become, much in the same way the entire population does not fix cars and build houses because they are not interested in those things.
A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses.
They aren’t. I want protocol level affordances for things like emoji reactions, custom emojis, threads, and such. On top of that I want the protocol to change as folks want to experiment with new things. Extensibility is a feature for me, not a bug. Also, I don’t really think a world where the UX is left in the hands of “interested” is realistic. Gemini still doesn’t have a rich client because technologists aren’t interested in one, and no surprise, the users are almost all technologists or their close, nerdy friends.
Regardless I think you and I won’t really see eye-to-eye on this issue, so I wish you the best.
Whether communication itself changes is perhaps debatable – my understanding is that, at least in the technological realm, the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.
Sometimes, the constraints of a system determine the patterns of communication, which are then codified into social norms, as you say (IRC favours shorter, plain-text messages, email has “etiquette”, etc.) As more people take part in a platform, it’s inevitable that more and more of these constraints, justifiable as they may be, will become issues that require solutions, features. If the platforms don’t evolve, people will look to move elsewhere, naturally.
The issue here isn’t the features or the changing expectations or even boxed platforms themselves, but rather that extending a platform with no regard for backwards compatibility tends, in the long term, to exclude people from being able to participate as freely as possible, or at all.
Even more so, these “moving” platforms impose their own constrains, which in turn become social norms; people don’t expect to have access to their archive, nor are they expected to be able to see out the lifetime of their devices (though this is an issue way beyond communication platforms.)
Federated or community-owned platforms are better in that regard since interoperability concerns will typically govern their evolution, and thus ensure at least some form of long-term viability and graceful degradation. Extending these platforms with additional features entails more effort, but it does happen – modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set (not everyone has the resources to own a recent, or any, smartphone, and there’s workable XMPP and IRC clients all the way down to J2ME.)
It basically comes down to this: for me, being able to communicate without fear of falling out of some compatibility cliff is more important than chasing new forms of expression; in lieu of not being able to say anything, I’d rather not be able to express myself in full colour.
the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.
I would like to push back on this but have run out of time to offer some examples. At the risk of being hasty, take a look at Sea Shanty riffs on TikTok. That form of cultural expression isn’t happening on IRC that’s for sure. (In fact, the image of someone trying to sing or rap on IRC reminds me of NWA and their entry into mainstream music, but that’s too off-topic to be more than an aside on Lobsters.)
But I agree with the rest of your post. I also think that community owned communication platforms have a greater incentive to respond to and support members of the community because their incentives are not driven by investors or customers in the same sense. I’ve watched the Fediverse take shape in a very community-oriented way and have had my heart warmed by watching folks organize in a multitude of ways (from mods having fun, to co-ops, to corporations) to enable their users to communicate.
modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set
imagine the following situation:
you use an xmpp client that is very simple, it only supports plaintext
you send a question to someone
they send their answer as an animated gif
your xmpp client does not support animated gif, you are not able to read the answer.
This does, of course, happen all the time, as people participate with less featured clients, or clients that do not support much more than text communication (e.g. terminal clients).
XMPP is actually a good example of how clients are able to fall back to at least a workable baseline, despite any new protocol-level features or changes. For example:
For P2P file-transfers (e.g. Streams, Jingle), feature negotiation takes place and the sender is required to ensure that the recipient supports the method used. If not the method will not be offered in the first place, which is arguably better than sending into the void.
For client-server file-transfers (e.g. HTTP upload), the recipient will generally see an incoming HTTP URI as a text message, if no other support exists (e.g. for inline display, etc.)
For things like threads, reactions/message attachments and the like, context is usually collapsed and the messages will appear as they would normally in the course of discussion.
Ideally, all clients would be able to support all features and these sorts of ambiguities would not exist, but it’s clear that some people aren’t able or willing to participate in the same way as everyone else. And though part of communication is in its intent (after all, a thumbs-up emoji attached to a message is not the same as one posted inline ten messages below), at least these additional features don’t form an “invisible” layer of communication above the baseline.
I think Matrix is a good attempt at pushing an open product first and an open protocol second. TFA notes that Element is wedded extremely closely to the Matrix spec, which makes it hard to implement, but I think this prioritization of product over protocol is necessary to deliver actual, sticky value to users. Open, federated software needs to enable users firstly; Matrix does document its decisions and open up its spec, but features are driven through the Element experience, which is where the real value for the user comes from.
I think there is a lot of truth to what you’re saying, but only up to a point. It’s fine to go the Matrix route as long as there’s a point at which the organization hits the brakes, slows down rapid iteration, and focuses on helping the rest of the ecosystem catch up.
I think that Matrix is at a good point for the feature-slowdown to begin.
I’ve tried to onboard friends onto Matrix and they still would like to see more features. Threads come up frequently, and so do custom emojis. We are starting to see more care toward stability in the ecosystem but I think it’s a bit early yet for feature development to stop. Protocol documentation is improving and alternate servers are being birthed (like Conduit). I think client complexity is not explicitly a concern of Matrix, so slowing down now would not help the project achieve it’s goals.
Obviously, having some unique features is great; problems arise when the number of unique features crosses a certain threshold. Following both these practices encourages implementations to stick to standards compliance, reliability, and compatibility rather than “innovation”. Choose boring technology over shiny new features.
Try venturing outside the mainstream by taking a look at a less popular provider or client. All implementations start somewhere, and a diversity of implementations prevents a rule by oligopoly.
I really think this is missing the forest for the trees. Users use software as tools, to further what they can do. Folks care about open platforms so that people can continue to use these tools without paying fealty to some corporate, government, or otherwise overlord. Telling folks to not use the things they care about defeats both the purpose of software and the value that open protocols hold onto. After all, the trivial case of software without value capture is software that has no value at all, or no software! You can’t lock my communication platform if I don’t actually communicate with another human.
SSH: Only OpenSSH matters. Even MS gave up and forked OpenSSH for Windows(and now is upstreaming their changes)
Version Control: Only 1 exists in any count that matters: Git, despite being mostly user-hostile for beginners/new people and even “seasoned” developers need cheat sheets.
Just to play devil’s advocate, there are several different implementations of Git, see: https://en.wikipedia.org/wiki/Git#Implementations, for example. So, in some sense, Git as a protocol for version control has been at least moderately successful.
yes, there are tons of various implementations of the git protocol in various languages, but.. do any of them have any use?
Microsoft’s version they use in-house is probably the only one that gets any serious use, and they are upstreaming the stuff that applies.
Pretty much all the other 3rd party implementations I’ve ever seen are either libraries that get some use(but usually use git’s C code under the hood and are mostly wrappers for a given language) or are implementations by random people trying to understand how in the world Git works, since the git UI is basically the thinnest possible wrapper around the protocol.
FreeBSD just threw in the towel and moved to Git, because they couldn’t convince anyone to use SVN any longer.
I would venture to guess trying to find any startup or tech company that doesn’t use GIT would be nearly impossible to find. Outside of that universe, there is a little usage, but that’s just because they haven’t caught up yet. I imagine they will all move to Git in the near-ish future, creating even more of a VCS monoculture.
My personal fav. VCS is Fossil, but other then SQLite, it gets basically no use.
It makes me sad, probably most developers would be better off with SVN/HG/Fossil as the UI is sane and pretty easy to understand and harder to get wrong.
It makes me sad, probably most developers would be better off with SVN/HG/Fossil as the UI is sane and pretty easy to understand and harder to get wrong.
I’m fossil-curious, but no history rewrite/rebase is a dealbreaker for me. Of course, it works for SQLite’s use case, so they’re not obligated to do a thing to bend to my whims.
I get people wanting to change history to clean stuff up, but that’s not what actually happened, you commit messy, you get messy. Auditors, governments, lawyers, etc want actual history.
That is an anti-feature for their use-case. They have contracts in defense/aerospace(forget which), that require the source be non-fungible. I’m too lazy to look up the link where they talked about it, but basically they can’t change history to keep auditors, contracts, etc happy. Sure it could be done outside of a VCS or it could be done in a different way, but that sounds like MORE work.. I’m lazy :)
I decided against using the cheeky sub-heading “Scaling considered harmful” because I worried that readers on a certain orange-colored website might take the joke too seriously.
It is certainly a nice article, with food for thought. It appearently embraces a spec-driven development model; I have never seen instant messaging compared with programming language development. This unusual comparison asks for it being challenged; maybe the difference is that programming languages target technical users only?
Spec-driven development is how XMPP works. There is a base protocol (RFC 6120, RFC 6121) and a plethora of separately standardised extensions called XEPs. These XEPs are supposed to improve through a life cycle starting from Experimental status and ending in a Final status; if no work happens on a XEP, it is declared “Deferred”. I think this model can be considered failed, because if you take a look at the actual XEP list, you will notice that almost all XEPs which constitute a “modern” chat client are either Experimental or Deferred, and this does not really change much over time. Effectively, one client (Conversations) just implements something and then it hits the standardisation process. That real model is much more closely to what is described in the original article – effectively, one implementation draws with it everyone else. Maybe we have to accept that this is a base line for “modern” development and “innovation”; unless of course you dispute that “innovation” is a bad goal in itself (which I’d like to point out is an absolutely valid opinion, though will probably get challenged). (Disclaimer: I have tried to implement an XMPP client myself without using an external XMPP library; I don’t think I will further work on it at this point, but the basics did work last time I touched two years ago or so)
If for a moment we accept that the one-implementation-drives-the-field model is necessary or at least happens every so often due to lack of active competitors, we then need to focus on how to keep the relevant field open despite of this. In the EU we have discussions about mandating federation by law, for instance. Maybe there are other ways that do not necessaryly involve lawmakers?
This is an important thing to think about. I’m trying to develop an open, interoperable chat platform myself, but it’s tricky while the project is small. I’d welcome someone developing another implementation to interoperate with, but I lack the free time to build one. We have been pretty careful with the spec, so I think it shouldn’t be hard to build another implementation.
If you’re interested in a young chat platform that aspires to these ideals, you can find us at https://arbor.chat
I certainly hope to steer clear of many of the traps described here though. My dream is to achieve financial sustainability for the project while also providing a fantastic collaboration tool.
a world where applications are spec-driven (or protocol-driven) sounds like a nice place to live, unfortunately i don’t think it works in reality. even if i look at the examples of spec-driven platforms provided by the article, many of those i consider failed:
i’m trying to think about applications meant for non-technical users, where the is a “spec” rather than an app. web-browsers are such a thing i guess? and even there, we only have 2 (or 3,depending how you count) “real” implementations.
It was (is?) so much worse than that. You could have two clients that implemented file transfer and video calls, but using different extensions and so they couldn’t interop.
One of the big problems here is that most users do not know the difference between a protocol, service, service provider, and app. They see Hotmail or Gmail or WhatsApp as monolithic things. They use the client provided by the service and they see the client, service, and service provider as a single monolithic entity. A few may sometimes use an additional client, but often don’t realise that they’re still using the same service when they do.
Signal gave up on trying to educate users here. The Signal service, protocol, and app are all presented as a uniform blob. I suspect that this is the biggest reason why Signal is the most successful open messaging platform.
And somehow it goes even further! Just the other day a friend told me that her mother got a new Facebook account because she got a new phone and thought her Facebook account was linked inextricably to the physical device she used to access it. I also have heard a number of anecdotes where people sign up for a new Gmail account each time they get a new Android phone.
If people want federation and open protocols to succeed they should stop writing new software and specs and start working out how to explain the whole idea to users and make them care about it.
Fediverse is barely a spec. Mastodon only implemented the S2S portion of the ActivityPub spec and even then only a subset of it. Mastodon still uses a bespoke API to talk to its clients and the client/server situation is a mess. The only 3 well-supported S2S implementations I know are Mastodon, Pleroma, and honk. I don’t even want to get into all the issues with ActivityPub.
You are absolutely correct. I considered including Mastodon as an example of an implementation with too many idiosyncratic features, but I don’t know enough about it. Maybe you could make a blogpost in response!
BitTorrent was originally the name of both the protocol and the client. Later people used the same protocol to build other clients, but the original model wasn’t too different from e.g. Signal. This is probably a major reason for its success. If it had used the “XMPP model” of just publishing a specification (or a specification with a client as an afterthought) then it probably never would have become as popular as it did.
The same more or less applies to the web: Berners-Lee didn’t just publish a bunch of specifications, he published a HTTP server, web browser, and web editor. And the web’s later mainstream growth was driven by products (Netscape and IE mainly) rather than specifications.
To be fair, Jabber was the protocol of a reference implementation with corporate backing first, then the IETF spec came later. That was just so long ago in internet years that it’s barely relvant anymore
That’s really interesting! I’d love to see someone write a post called “Opening closed platforms”.
Neither were ever a “closed” platform; it’s just the difference in focus/communication:
Publish an open protocol, market/communicate the protocol, and wait for people to write clients for it.
Publish and open protocol and write a good (or at least decent) open implementation of it, and mainly advertise the implementation rather than the protocol.
Not necessarily, take the example of sockets. As the language is extensible, a library can abstract over implementations extending the language. The same applies to threads, for example. Then all other libraries depend on these projects, instead of implementations.
Let’s not forget IRC, where implementing a server is almost not-possible by just reading the RFCs. Everyone likes to talk about how easy it is to implement a client, but a server is a whole other can of worms.
This is a less philosophical and more actionable follow-up to my previous article, “Whatsapp and the domestication of users”. Unlike the previous article, this one focuses on more technical solutions: spec-driven development and implementation diversity.
Feedback welcome, as always.
I haven’t seen very many good arguments against what Moxie has said with regards to competing on features. Comparing this with countries - even in a representative democracy like the United States, our military is a strict hierarchy. This is despite the democratic principles of the country. The reason? There is an evolutionary pressure on militaries to find the most competitive structure - those who have tried other things (as Orwell talks about in revolutionary Catalonia) failed in part due to the structure they adopted. Moxie has noticed the loss of open source projects to these closed companies due to their insistence on a more virtuous structure and has decided that the perfect is the enemy of the good. To me this seems analogous to the arguments between pure utopian anarchists and more pragmatic people (considering Moxie’s political orientation he is probably intimately aware about the tradeoffs here).
Since reading Moxie’s polemic against federation (I assume you’re talking about the “Ecosystem is Moving” essay, though Moxie has repeated the idea elsewhere), I’ve slowly come to the understanding that the only way to win this competition on features is to not play at all. After all, there’s almost always someone out there with more money/determination than you, which I guess is especially true in terms of open/community-owned projects vs. more commercial endeavors.
Part of what I’ve come to dislike about these more boxed platforms (to borrow a term from the linked article) is how they’ve made online discussions more ephemeral, both in terms of owning one’s archive, and in terms of being able to stay part of a community regardless of which device/system I happen to be participating from. For most of these platforms, clients running on “legacy” systems (be it older devices or devices on non-mainstream operating systems) are routinely dropped or not developed for in the first place; some platforms place constraints on participating over multiple/alternative devices, such as a mobile device and a desktop device (ostensibly because of E2EE concerns).
This contributes to my nagging feeling that I’m somehow forced, as a user, to keep up with some notion of progress, when all I want is to communicate.
Conversely, platforms such as IRC and XMPP continue to be useful even on ancient or under-powered devices, albeit in a perhaps degraded capacity, and allow for the sort of mixing-and-matching of use-cases made harder by their boxed counterparts. This, to me, is a more user-friendly and inclusive approach to building communication tools; unfortunately, being more inclusive means taking the foot off the pedal, or at least taking a more mindful approach in rolling out features.
Communication (like most human endeavors) is constantly changing. Language changes, communication methods change, speakers change (including marginalized groups into conversations), and expectations around media change. This isn’t “progress” in the Baconian sense but it is change. IRC and XMPP (along with their technical issues which others in this thread have covered in great detail) just hasn’t been able to keep up with changing expectations of communication. Realistically, the general population sends pictures of computer monitors to their friends over Snapchat. Sticking to IRC just codifies a different set of social norms into place.
Disagree.
Communication over platforms typically changes because the platforms themselves change. People started sending each other image file attachments instead of image links after image attachments were implemented by popular clients.
Featuritis causes these changes more often than change causes featuritis. Language changes, but those changes can still be represented in plaintext as long as encodable written language exists.
You’re taking too short of a view of this. Humanity used to send smoke signals and use oral storytelling to communicate. In the meantime, we seem to have invented writing, paper, printing presses, newspapers, telegraphs, radios, and all sorts of other manners of communication. Whenever I see folks say things like change is driven by featuritis, I invite folks to tell me where they draw the line between essential change and featuritis change and to justify why this line is valid.
Right but what about folks that are hard of sight? Folks that are dyslexic? People that comprehend things through image better than text? Traditionally these folks have been excluded from the conversation. In fact, the history of communication has largely followed the democratization of communication to new actors. Why is plaintext encodable written language the point at which we must draw our line in the sand?
EDIT: I also want to point out that there are people that enjoy change. They enjoy learning new slang, they love participating in new memes, trends, conversations, and ideas. This isn’t to say that new is inherently better, but nor is it to say that new is inherently worse. But there is a contingent of people out there that legitimately enjoy change. If you want to include folks in the conversation (which is the whole point of creating open communication platforms, right, to enable humanity to communicate), you need to account for folks that will change their colored contacts on a whim as much as the person who is fine using their 20 year old laptop to view plain text.
Dictation does not require creating a new protocol; that’s a client-side feature.
Because that’s the minimum requirement for communicating language, and the most accessible form of communication in existence.
Client-side change is fine as long as that change doesn’t devolve into a boxed platform. Nobody’s stopping you from switching out themes or clients when you feel like it.
What about sending voice messages? Sending images? Am I not allowed to hear my parents’ voices because of protocol complexity? What about folks that are blind and deaf, or who don’t know a certain language?
Citation needed. We communicated without written language for a very long time. Why do we need to use written language now? How is it the minimum of anything? We don’t even have a universal theory of human semantic processing, so how can we prove that written communication is the minimum?
But why are you so invested in trying to limit my expression? Why must we embrace minima? Because it’s easier for the implementer? Why is the implementer more important than the user? Why is an open protocol more important than the act of communication itself? When I check out a new apartment to rent and I see it doesn’t have central heating, I don’t think to myself “ah of course, what a smart design decision, the builders decided to save on complexity” I think “oh they cut corners and either did not renovate in central heating or they don’t care to support central heating, well, not my sort of place”.
This is the problem that folks bring up when talking about open source adoption. Open source often cares more about principles than usage. FOSS cares more about openness, customizability, and other values that end users care for less than core functionality. If you want to communicate with your fellow FOSS-natives on Freenode and grumble about the kids on TikTok be my guest, but others will not be willing to make that choice. If FOSS actually wants to enable end users and not technical FOSS-natives, then FOSS needs to prioritize users just as much if not more than its principles. In the meantime, others will explore other tradeoffs. Like Moxie with Signal, Element with Matrix, and Gragon with Mastodon. I can tell you that IRC hasn’t changed much and FreeNode hasn’t gone anywhere in the last several decades, yet the mindshare has very much moved away from FreeNode, and that’s because users have put their “money” (or time or effort or whatever) where their mouth is and have voted with their feet.
For me a good metric of success with a communication protocol/product will be when you observe average teenagers in the developed and developing world organically using your product to communicate. They use things like Instagram and WhatsApp but they probably don’t use IRC. I did use IRC when I was a teenager, but there were fewer options then and IRC mirrored the cultural context of online communications at the time much more than IRC does now. I think you’d be hardpressed to get any teenager these days to use IRC.
Use the right tool for the job. A VOIP protocol would work well for sending voice. You could make a meta-client that combines a VOIP client and an instant-messaging client if you want to do both at the same time. There are better ways to do this than making the protocol more complex.
People who are both blind and deaf can use braille readers. Plaintext allows people who are sighted, blind, and/or deaf to interpret language.
Yes. I explained my rationale for simplicity in the previous post, Whatsapp and the domestication of users. When complexity grows past a certain point, implementers need to spend more working-hours and need more funds to create a viable implementation; requiring too much funding can encourage dark patterns and conflicts of interests (e.g., investor money). I’d recommend checking out the article if you’re interested in this topic.
Open protocols are important because the act of communication is so important. Nobody should in control over the means of communication.
Agreed; however, if I don’t notice a golf course in the background I’d probably feel relief rather than anger since that’s a bit more than I bargained for. A golf course isn’t part of the “house spec”. A stable temperature, on the other hand, is part of the minimum requirements for a house and should be included in the “house spec”.
Correct. These are ideological movements. They support ideologies, and reject the notion of the “end justifying the means” (the way the phrase is commonly used).
I’ve explained why I find Signal problematic in the previous post. I don’t think one org should own a communication platform.
I was a teen on IRC until last year when I turned 20. There are dozens of us!
Also, a quote from this article:
I’m not trying to get the aforementioned stereotypical “teens” to suddently sign up for a FSF membership and install Libreboot (though that would be nice). I’m trying to get technical users to start caring, since they’re the ones who can influence their friends’ technical decisions, file bug reports, and make the software better. That needs to happen for the “teenagers” to sign up.
Freedom of protocol and implementation is not worth enough for me to relegate impaired readers to second class citizens that someone has to think about. If anything, that sounds like prioritizing the freedom of the able over the freedom of anyone else.
For me communication is not worth gimping for the sake of being minimal or implementation-friendly. I am fine accepting complexity in client, protocol, and server to enable users to communicate in novel, ergonomic ways. Communication is much more important to me than implementer ease. I’ll go further and say, given a choice between implementer ease and rich communication, almost everyone would pick rich communication. Only a minority will be so motivated by the spectre of lock-in that they will reject attempts to broaden the platform.
This is part of your personal “house spec” of course. I think you’re going to have a really hard time finding everyone agree on a “house spec”, and in practice you see folks with very different types of living domiciles based on their preferences. In college, I had friends who lived without central heating and wore thick jackets to use the bathroom. This was their choice.
For me and many other technologists, technology is primarily about the user and the human component, only secondarily about protocols, implementer ease, ideology, or anything similar. I view technology as slave to the human, not human as slave to the technology. I think you’re going to have a hard time convincing tech users like us otherwise. After all, we’ve had decades of IRC, and even among technologists IRC has lost ground, not gained it. I’m sad to say I don’t think this viewpoint has any bite except among a dedicated few, who will continue to stick to IRC and grumble about new protocols and their freedoms.
“Man is born free, yet he is everywhere in chains”
I agree, and this is the reason why I think we should build everything we can from plaintext. Audio excludes the deaf, visual excludes the blind, but plain text includes the largest possible audience. Text is the most accessible format in existence, while other formats treat many disadvantaged users as second-class citizens.
Agreed. In order for people to be in control of their platforms (rather than the other way around), the platform should not be owned by anyone. For technology to be a slave to the user, the technology should be owned by none other than the users themselves.
A lot of your concerns about UX are client issues rather than protocol issues. It’s perfectly possible to build a glossy, animation-rich client with nice colors and icons that can appeal to the masses. The benefit of open platforms is that you get that choice without excluding users on low-end devices who can’t afford to run a fancy Electron app. Open platforms are a means to include everyone and serve the human rather than the platform owner. If your use-case isn’t met, you can build an implementation that meets it.
Minority users matter too.
I just don’t agree, and without studies to back this viewpoint up, I’m going to take this as an ideological viewpoint.
Indeed, but I think you and I have different definitions of ownership. Simplicity and ease of implementation are not prerequisites for ownership in my mind. That simply passes the buck to the technologists, of which ideally we wouldn’t force the entire population to become, much in the same way the entire population does not fix cars and build houses because they are not interested in those things.
They aren’t. I want protocol level affordances for things like emoji reactions, custom emojis, threads, and such. On top of that I want the protocol to change as folks want to experiment with new things. Extensibility is a feature for me, not a bug. Also, I don’t really think a world where the UX is left in the hands of “interested” is realistic. Gemini still doesn’t have a rich client because technologists aren’t interested in one, and no surprise, the users are almost all technologists or their close, nerdy friends.
Regardless I think you and I won’t really see eye-to-eye on this issue, so I wish you the best.
Whether communication itself changes is perhaps debatable – my understanding is that, at least in the technological realm, the tools we have for communicating (e.g. inline images/audio/video, emojis, and what-not) evolve and change, but the underlying needs for expression remain the same.
Sometimes, the constraints of a system determine the patterns of communication, which are then codified into social norms, as you say (IRC favours shorter, plain-text messages, email has “etiquette”, etc.) As more people take part in a platform, it’s inevitable that more and more of these constraints, justifiable as they may be, will become issues that require solutions, features. If the platforms don’t evolve, people will look to move elsewhere, naturally.
The issue here isn’t the features or the changing expectations or even boxed platforms themselves, but rather that extending a platform with no regard for backwards compatibility tends, in the long term, to exclude people from being able to participate as freely as possible, or at all.
Even more so, these “moving” platforms impose their own constrains, which in turn become social norms; people don’t expect to have access to their archive, nor are they expected to be able to see out the lifetime of their devices (though this is an issue way beyond communication platforms.)
Federated or community-owned platforms are better in that regard since interoperability concerns will typically govern their evolution, and thus ensure at least some form of long-term viability and graceful degradation. Extending these platforms with additional features entails more effort, but it does happen – modern XMPP clients are quite feature-ful and pleasant to use, though still behind the various proprietary platforms in some ways. It still, however, remains possible to participate on clients operating against a reduced feature-set (not everyone has the resources to own a recent, or any, smartphone, and there’s workable XMPP and IRC clients all the way down to J2ME.)
It basically comes down to this: for me, being able to communicate without fear of falling out of some compatibility cliff is more important than chasing new forms of expression; in lieu of not being able to say anything, I’d rather not be able to express myself in full colour.
I would like to push back on this but have run out of time to offer some examples. At the risk of being hasty, take a look at Sea Shanty riffs on TikTok. That form of cultural expression isn’t happening on IRC that’s for sure. (In fact, the image of someone trying to sing or rap on IRC reminds me of NWA and their entry into mainstream music, but that’s too off-topic to be more than an aside on Lobsters.)
But I agree with the rest of your post. I also think that community owned communication platforms have a greater incentive to respond to and support members of the community because their incentives are not driven by investors or customers in the same sense. I’ve watched the Fediverse take shape in a very community-oriented way and have had my heart warmed by watching folks organize in a multitude of ways (from mods having fun, to co-ops, to corporations) to enable their users to communicate.
imagine the following situation:
This does, of course, happen all the time, as people participate with less featured clients, or clients that do not support much more than text communication (e.g. terminal clients).
XMPP is actually a good example of how clients are able to fall back to at least a workable baseline, despite any new protocol-level features or changes. For example:
For P2P file-transfers (e.g. Streams, Jingle), feature negotiation takes place and the sender is required to ensure that the recipient supports the method used. If not the method will not be offered in the first place, which is arguably better than sending into the void.
For client-server file-transfers (e.g. HTTP upload), the recipient will generally see an incoming HTTP URI as a text message, if no other support exists (e.g. for inline display, etc.)
For things like threads, reactions/message attachments and the like, context is usually collapsed and the messages will appear as they would normally in the course of discussion.
Ideally, all clients would be able to support all features and these sorts of ambiguities would not exist, but it’s clear that some people aren’t able or willing to participate in the same way as everyone else. And though part of communication is in its intent (after all, a thumbs-up emoji attached to a message is not the same as one posted inline ten messages below), at least these additional features don’t form an “invisible” layer of communication above the baseline.
I think Matrix is a good attempt at pushing an open product first and an open protocol second. TFA notes that Element is wedded extremely closely to the Matrix spec, which makes it hard to implement, but I think this prioritization of product over protocol is necessary to deliver actual, sticky value to users. Open, federated software needs to enable users firstly; Matrix does document its decisions and open up its spec, but features are driven through the Element experience, which is where the real value for the user comes from.
I think there is a lot of truth to what you’re saying, but only up to a point. It’s fine to go the Matrix route as long as there’s a point at which the organization hits the brakes, slows down rapid iteration, and focuses on helping the rest of the ecosystem catch up.
I think that Matrix is at a good point for the feature-slowdown to begin.
I’ve tried to onboard friends onto Matrix and they still would like to see more features. Threads come up frequently, and so do custom emojis. We are starting to see more care toward stability in the ecosystem but I think it’s a bit early yet for feature development to stop. Protocol documentation is improving and alternate servers are being birthed (like Conduit). I think client complexity is not explicitly a concern of Matrix, so slowing down now would not help the project achieve it’s goals.
I really think this is missing the forest for the trees. Users use software as tools, to further what they can do. Folks care about open platforms so that people can continue to use these tools without paying fealty to some corporate, government, or otherwise overlord. Telling folks to not use the things they care about defeats both the purpose of software and the value that open protocols hold onto. After all, the trivial case of software without value capture is software that has no value at all, or no software! You can’t lock my communication platform if I don’t actually communicate with another human.
Other “open” but effectively closed systems:
SSH: Only OpenSSH matters. Even MS gave up and forked OpenSSH for Windows(and now is upstreaming their changes)
Version Control: Only 1 exists in any count that matters: Git, despite being mostly user-hostile for beginners/new people and even “seasoned” developers need cheat sheets.
Just to play devil’s advocate, there are several different implementations of Git, see: https://en.wikipedia.org/wiki/Git#Implementations, for example. So, in some sense, Git as a protocol for version control has been at least moderately successful.
yes, there are tons of various implementations of the git protocol in various languages, but.. do any of them have any use?
Microsoft’s version they use in-house is probably the only one that gets any serious use, and they are upstreaming the stuff that applies.
Pretty much all the other 3rd party implementations I’ve ever seen are either libraries that get some use(but usually use git’s C code under the hood and are mostly wrappers for a given language) or are implementations by random people trying to understand how in the world Git works, since the git UI is basically the thinnest possible wrapper around the protocol.
Subversion is widely used as well, especially in Enterprise contexts.
FreeBSD just threw in the towel and moved to Git, because they couldn’t convince anyone to use SVN any longer.
I would venture to guess trying to find any startup or tech company that doesn’t use GIT would be nearly impossible to find. Outside of that universe, there is a little usage, but that’s just because they haven’t caught up yet. I imagine they will all move to Git in the near-ish future, creating even more of a VCS monoculture.
My personal fav. VCS is Fossil, but other then SQLite, it gets basically no use.
It makes me sad, probably most developers would be better off with SVN/HG/Fossil as the UI is sane and pretty easy to understand and harder to get wrong.
I’m fossil-curious, but no history rewrite/rebase is a dealbreaker for me. Of course, it works for SQLite’s use case, so they’re not obligated to do a thing to bend to my whims.
I get people wanting to change history to clean stuff up, but that’s not what actually happened, you commit messy, you get messy. Auditors, governments, lawyers, etc want actual history.
That is an anti-feature for their use-case. They have contracts in defense/aerospace(forget which), that require the source be non-fungible. I’m too lazy to look up the link where they talked about it, but basically they can’t change history to keep auditors, contracts, etc happy. Sure it could be done outside of a VCS or it could be done in a different way, but that sounds like MORE work.. I’m lazy :)
Oh, I know. Again, it makes sense for them, but it’s not what I want, so I don’t use it.
I learned SVN at my apprenticeship because we use it in the company and also learned it again at university, because we used it there as well. 😅
A very well-written, insightful and constructive article.
Also thank you for just using an accurate title!!
While it didn’t get any attention here, you might enjoy https://lobste.rs/s/src11s/is_privacy_all_our_interests
It is certainly a nice article, with food for thought. It appearently embraces a spec-driven development model; I have never seen instant messaging compared with programming language development. This unusual comparison asks for it being challenged; maybe the difference is that programming languages target technical users only?
Spec-driven development is how XMPP works. There is a base protocol (RFC 6120, RFC 6121) and a plethora of separately standardised extensions called XEPs. These XEPs are supposed to improve through a life cycle starting from Experimental status and ending in a Final status; if no work happens on a XEP, it is declared “Deferred”. I think this model can be considered failed, because if you take a look at the actual XEP list, you will notice that almost all XEPs which constitute a “modern” chat client are either Experimental or Deferred, and this does not really change much over time. Effectively, one client (Conversations) just implements something and then it hits the standardisation process. That real model is much more closely to what is described in the original article – effectively, one implementation draws with it everyone else. Maybe we have to accept that this is a base line for “modern” development and “innovation”; unless of course you dispute that “innovation” is a bad goal in itself (which I’d like to point out is an absolutely valid opinion, though will probably get challenged). (Disclaimer: I have tried to implement an XMPP client myself without using an external XMPP library; I don’t think I will further work on it at this point, but the basics did work last time I touched two years ago or so)
If for a moment we accept that the one-implementation-drives-the-field model is necessary or at least happens every so often due to lack of active competitors, we then need to focus on how to keep the relevant field open despite of this. In the EU we have discussions about mandating federation by law, for instance. Maybe there are other ways that do not necessaryly involve lawmakers?
This is an important thing to think about. I’m trying to develop an open, interoperable chat platform myself, but it’s tricky while the project is small. I’d welcome someone developing another implementation to interoperate with, but I lack the free time to build one. We have been pretty careful with the spec, so I think it shouldn’t be hard to build another implementation.
If you’re interested in a young chat platform that aspires to these ideals, you can find us at https://arbor.chat
I certainly hope to steer clear of many of the traps described here though. My dream is to achieve financial sustainability for the project while also providing a fantastic collaboration tool.
Thanks, bookmarked. I’ll watch its development with interest.
You’re welcome to drop in and say hi! https://man.sr.ht/~whereswaldon/arborchat/getting-started.md