On the other hand, #Matrix's bridge to #Freenode seems to powercycle at least once per day, resulting in me being kicked out of rooms unless I identify to NickServ quickly enough. (If the #IRC side kicks you, the Matrix side obliges ... and the Element client does not even save that room so you can rejoin easily after you identify.
I dislike rejoining "#freenode_#roomname:matrix.org" so frequently. Maybe I should set up a bouncer and use and IRC client.
I was surprised to find that I didn't even have an IRC client installed on this laptop.
I guess that is a sign that I am free to move to LiberaChat ... but I may just wait until #Matrix has bridging to that network and then allow it to create an account for me.
Thinking that there might be a reason to add #Funkwhale to the list ... with some restrictions (requires #Federati Networks account, original content only, moderated; possible fundraising may be needed as file storage requirements expand)
Also, already planning to add #XMPP, #Movim, #Mattermost chats, but considering trying out a #Matrix instance (preferably something other than Synapse) to see how well bridging to XMPP MUCs works. I'm sure the Matrix team has never considered a setup where only rooms bridged from $PROTOCOL and possibly also $INSTANCE can be created locally.
It is still very early in its life, so it should improve over time.
There's a few things that need to improve: * It is designed for iPhones, so it looks awkward on an iPad. * After I set it up and logged in, there was an update. After the update, I had to set it up again. It didn't retain my login session or information. * It doesn't pick your homeserver as the place to log into when you enter the normal "username:homeserver.tld" syntax. You have to click the magnifying glass icon and enter your (homeserver.tld).
These things can be fixed, and some likely will be fixed, as development continues.
I think the #blockwars folks may have indirectly caused this. There are people who file complaints against client apps that don’t build in blocklists against specific servers whose moderation policies they dislike.
I think that #Matrix / #Element competes with one or more Google-owned chat-type services. Since they gatekeep the overwhelming majority of Android users’ software installation, a good antitrust lawyer would be helpful. I’ll bet that faxing a bunch of documents to #USDOJ and various states would suddenly cause Google to decide that Element doesn’t violate their policies anyway.
(Someone said it was “Boomers at Google that don’t understand federation”, but first of all, I’m certain that most GOOG employees are far younger than you and I, and secondly, I’m sure someone at Google understands federation, though they obviously dislike not being in control. Google Talk was federated with #XMPP, while Google Plus was basically #Diaspora with federation stripped out.)
With #Matrix, the #Riot.im client was replaced by #Element, which is buggy. In the process, the upstream used to produce the #miniVector client was disrupted, so that client is discontinued. #Pattle's developer also decided to discontinued it.
I'll have to look around #F-droid to see what else is available.
There was a similar document shared on Secure Scuttlebutt ( #SSB ) / #Manyverse a while ago. I believe I linked the document, so search my history if you wish to compare.
Frankly, I found the SSB document unworkable and error-prone, but this one sounds like it could work in some situations.
Though I think they have a lot of stuff they already needed to solve. Trying to fix the #Matrix protocol itself and replace the #Synapse server with something more efficient, while porting features over from #Gitter (both the server and the client ends) is going to increase the strain on their development resources.
The recent migration from #Riot.im to #Element (on Android) is already dissatisfying, as the new client does not have all the capabilities of the old one and also introduced new bugs.
As a regular user of Matrix (who once considered hosting a homeserver), I see this mostly like Mozilla's Eudora mail client announcement several years back: "We already lack the needed resources for this project, so we're going to take on additional responsibilities".
But I don't object to others choosing such end-to-end encrypted messengers over messaging apps such as (for example) #Facebook_Messenger.
I personally use #Wire, #XMPP, #Matrix, and #WickrMe. (I tried #Jami, but it wasn't very usable yet; none of my contacts were willing to try #Tox or #Briar.) I've even considered getting a Google account again so I can use whatever their latest incarnation of messaging is (just because almost everyone I know has a Google account).
It does bother me that Signal and Telegram and most other messaging services are centralized and non-federated.
It seems we haven't learned from the 1990s & early 2000s when some friends had AOL Instant Messenger (AIM), some had MSN Messenger, some had Yahoo Messenger, some had ICQ, and a few had various other walled garden messengers (such as Excite's messenger). If I wanted to talk with all my friends, I needed to have accounts on every possible service. I should be able to communicate with my friends from whatever service I choose to use to whatever services they choose to use and not have to create accounts on every possible service.
But that's a matter of educating our friends and family, not of dogmatically refusing to communicate with them on any service they might use.
This sounds like a good idea, but (1) as a #Matrix user, I don't think the protocol or the implementing software are "ready for prime time" and (2) I don't see any sign that they have given much thought to NAT, firewalls, or DNS. An organization, once it has sufficient internally technology resources, could quickly get this working, but that sized org is just as likely to buy a real server and run their own chat & IM service (or contract it out to any of the "enterprise" vendors).
I think this targets home users and really small businesses without an IT background and should probably include (and talk about) some tools and services to make that use case realistic.