Tag: Matrix

By using a silo we exclude children

by

2021-07-16

14:03

Leave a comment on By using a silo we exclude children

Interweb, Matrix, politics

, , , ,

Teckids e.V. held their annual summer camp for kids between 9 and 15 years. This year, after we started introducing Matrix and Element as a chat platform … Some got really excited that they could even change or add features to Element … Unfortunately, Element is developed on GitHub, so the potential young contributors are locked out by the exclusive Terms of Use there. We are trying to reach out to Element HQ to find a solution.

Klampfradler writing in This Week in Matrix

Ironic but all too common: a Libre/FOSS project falling foul of the very issue it is trying to overcome. For this post, however, let us not focus on this particular situation. Let us instead learn from it how we can better explain why we need Matrix and other Libre systems.

GitHub only allows users over a certain age. Initially when we adults sign up, this seems like no big deal: it sounds like quite a young age (13) and it says it’s to comply with the law of the USA, which sounds obvious and unavoidable.

This is a great example of how we restrict other people’s freedom every time we choose a silo. We start off thinking the silo is reasonably inclusive and gives enough freedom for what we need. After all, it’s one we use, so by definition it’s good enough for people like ourself. But:

  • everyone we want to connect with has to obey the same terms, and
  • we don’t have any control over those terms.

Even when it’s “our project”, we can’t choose who we are allowed to collaborate with.

What if our situation changes, perhaps a long time later? Perhaps our friend has children who under the supervision of their parents are competent and keen to code. We might ask them to use their parent’s account. GitHub’s terms forbid that too. Anyway that would mean they couldn’t keep a record of their contributions linked to their own identity.

GitHub, being a silo, restricts the freedom of its users and the freedom of our collaborators and would-be collaborators.

By contrast, when we have control of our own Libre system, such as a self-managed GitLab, then we can set our own terms and conditions.

That’s a key benefit of using a Libre system.

It’s the same in any Silo-vs-Libre domain: Zoom vs Jitsi, WhatsApp vs Matrix. When we use the silo, we restrict not only our own freedom (which we may not immediately care about) but also the freedom of those we contact. We probably care more about the freedom of those contacts who are our real-life friends, family, and colleagues, who in turn care about their own friends and family.

In trying to convince people to switch to Matrix and other open tech, it can be hard to find “selling points” that resonate with ordinary people who are not already familiar with these freedom issues. As above, they think the silo they are using gives them as much freedom as they need. This point about how it impacts those they care about is one that the general public may be able to relate to, and recognise as important.

Let’s use this point to spread the message:

By using a silo we exclude children

Decoupling Identity in Matrix

by

2020-04-23

20:00

Leave a comment on Decoupling Identity in Matrix

-, Interweb, Matrix

, , 

For individuals, Matrix's identity scheme creates lock-in.
How to fix?

I love Matrix. I think it’s the way forward for libre/open (as in freedom) personal communications, with a real chance to free users from the lock-in of popular silo messaging systems like Whatsit, Facepalm and Twiddle. I run all my own messaging (except email) through Matrix, with bridges to the silos that my friends still use as well as SMS and IRC.

At present, unfortunately, there is a big obstacle to me recommending any friend or family member to sign up to Matrix: identity and server lock-in.

An Open system with lock-in? Ugh. What went wrong?

To use a silo, you register an account and either you are identified by your telephone number or you choose a username. (You can then set some account options, usually including a “display name” which you can change from time to time.) Now, what if at some point you dislike that silo’s rules or advertising or charging? You’re stuck. They deliberately designed the system so that nobody has any options other than continue or quit.

To use Matrix, you register an account on a server. You first need to choose a server, which is identified by its Internet domain name such as matrix.org, or mozilla.org, or my-own-server.my-name.me if you run your own server. You can find out which servers are available for public use. Some are free of charge and others require payment, similar to email services. Having chosen a server, you pick a username and are then identified globally as @username:servername . (You can also choose a display name.)

Matrix right now is great for an organization: running their own server on their own domain, they control their own rules and namespace for users, rooms and groups.

If you are a normal person, your default option is to register a username on ‘matrix.org‘. (In principle there will be other public servers but there are hardly any so far.) Then, that username is tied to that server forever, or at least until Matrix developers invent a way out.

This lock-in is different from a silo. At least with Matrix you can create a new account on another server, to get away if you don’t like the old one. What you can’t do (yet) is migrate your old account to the new one. Not in any way. See “Account Migration” below.

Bring Your Own Domain Name

One way to mitigate the account migration problem is to register an account under a server domain name that you control.

The point is, then, the user controls their own domain name registration, which is directly registered with a domain registrar, outside the control of and Matrix or other service provider. The user can keep their own domain and have it served by a new server in the future if the current server becomes unsuitable or unavailable.

How feasible is this, today?

  • A geek with time and skills can register a domain name and run their own server.
  • A person with some time and effort and money can register a domain name and pay for a hosted matrix server. The cost and effort is broadly similar to setting up a new phone or internet or TV service. It does require some investment of thought and learning what it’s all about.
  • A normal Whatsit user is used to “free and easy”, and there is currently no such option for them.

Hosted servers come with significant limitations on customizing your server. For example, on modular.im (currently the main hosting option), AFAIK you cannot run the Whatsit bridge.

What can we do to improve things for the normal user?

  1. make it cheap (not necessarily free)
    • Build a server that can serve lots of different people’s personal-domain user accounts. (This may be called a “multi-tenant” server design.) @mfilipe:matrix.org mentioned this today on #matrix-dev:matrix.org.
    • Spread the word that it’s sensible to pay for a service so that you are not the product being sold, unlike the free silos.
  2. make it easy
    • Build services in which a new user can set up a domain name and a matrix server or account at that domain, and pay for both with one payment. (Major providers of some services like email offer this.)
    • For people migrating from a specific silo, offer ready-to-use setups (bridging) and messaging (intro, and suggestions for how to tell the silo friends about it) that are customised for that case.
    • Make it easier for geeks to run matrix servers for their friends and family.

Who should be doing this? Not necessarily the Matrix Foundation or New Vector (who make Riot and Modular.im among other Matrix things). They have limited resources and their own priorities. It’s an open-source system so anyone wanting these things should get involved and start making them.

Good places to discuss and get involved in the self-hosting side include #matrix-docker-ansible-deploy:devture.com and #matrix-self-host-onboarding:chat.weho.st .

Account Migration

It would be useful to be able to migrate an old account to a new one in ways like:

  • forward messages to the new address
  • inform all contacts of the new address
  • set up an auto-reply
  • copy account settings
  • copy message history
  • copy a list of contacts

I was thinking about what is possible in email, and what regrettably isn’t available. Migrating an email account is not at all simple, but most of the mini-features above are possible to some extent. One thing regrettably missing in the email system is a way to automatically inform senders to an old account that they should update your address and re-send to a new account. (Like an HTTP “redirect”.)

It would be useful to develop those kinds of mini-features for making the transition to a new matrix account smoother. That might be a feasible short-term mitigation.

However, there is a better long term solution: decoupling accounts from identity.

Decoupling Identity

[TODO: Write about decoupling identity.]

Matrix Bridges Working Together

by

2020-02-06

13:41

Leave a comment on Matrix Bridges Working Together

Interweb, software design

I am testing SmsMatrix, an SMS-to-Matrix bridge on Android. It is one of many Matrix bridges. But this post is not mainly about SmsMatrix, it is mainly the start of a train of thought about how we can manage communications with one person bridged over different channels.

This is a write-up of thoughts I first posted to the SmsMatrix discussion room, which would be better continued on #bridges:matrix.org.

Let’s say my friend has telephone number 123456 and is in my phone’s address book as “Ray”.

When my phone receives an SMS from Ray, SMSMatrix sees that message arrive in the Android SMS subsystem, and (if it hasn’t previously done so) it creates a new Matrix direct-chat room which it will associate with the SMS sender’s phone number, and invites me to join the room.

The other participant in this room is the bridge bot. Its username is @sms-bot:my_hs, and it sets its own display name to “Ray”. I assume that is a per-room display name, so it will show as a different name in each SMS conversation. The bot does not set a room name, and so Riot displays it as “Ray” (the other participant’s display name), and the bot sets the room “topic” field to “123456”, which Riot displays next to the room name. The idea is that in the user interface it looks like I am having a chat with “Ray” and it works like I am having a chat with Ray.

In Riot-web’s message view, the sender of this first SMS message shows as (precisely) “sms-bot”. The display name of @sms-bot does seem to be correctly set to “Ray” — I can see that in the “users” panel. Perhaps that’s a Riot bug that it doesn’t always display the user’s display name.

This bot works without admin privileges. It can do so because it doesn’t try to create and control a new Matrix user for each SMS sender, nor does it try to find and puppet an existing “real” matrix user account corresponding to the sender.

I wonder if it would be nice to upgrade it to a puppeting bridge if I one day have enough time to devote to it. I’m wondering exactly what we could achieve if we did so.

I also have some other bridges, and let’s say Ray also has her own Matrix account on her own homeserver, where she calls herself by her full name “Radiator”. Now I have Ray’s messages coming in to me in these Matrix rooms/users:

  • @sms-bot:my_hs “Ray”
    • in room (unnamed) displayed as “Ray 123456”;
  • @whatsapp_123456:my_hs “Ray (WA)”
    • in room (unnamed) displayed as “Ray (WA) WhatsApp private chat”;
  • @telegram_123456:my_hs “Ray (TG)”
    • in room (unnamed) displayed as “Ray (TG)”;
  • @ray:rays_hs “Radiator”, Ray’s real Matrix user account
    • in room named “Ray”

The mautrix-telegram and mautrix-whatsapp bridges each create a new user id for Ray in their own namespace of matrix user-ids, which is different from the SMS bridge.

I am interested in researching how we could improve this situation. Would we want to make all bridges to the same person somehow bridge to the same Matrix user?

@pwr22 asked, “How would the bridge know which method to use when sending a message?” That’s a good UX question. The first thought coming to my mind is that’s easy if we dedicate a separate room for each bridge for that user. (Ray’s SMS chat room, Ray’s Telegram chat room, …).

“In that case what do we gain from having one puppet user instead of separate ones per service?” We gain things like,

  • “search for all messages from @ray [containing the word ‘zoo’]”,
  • “search for the rooms that @ray is in”.

I expect users would want to choose, by their own preferences and perhaps per contact, whether a contact’s messages are all grouped in the same room or a separate room per bridge.

If I want to group all Ray’s messages into one room, then the sending UX issue must be solved a different way. Perhaps the client would allow me to set a preference. (That could be stored as client-managed metadata, like how Riot stores some settings in “account data” under “im.vector.riot.xxx” keys.) And/or there could be bot commands so I can tell a bridge "!sms-bot: enable [or disable] sending outgoing messages in this room through SMS".

In response to my thought about making all bridges bridge to the same Matrix user, @swedneck replied, “i’m not sure that’d make sense. i would probably have all those bridges in the same room if possible. you’d probably want his bots to ignore each other though.” So:

  • one room (“My direct chat room with Ray”) containing
    • myself,
    • the virtual user @sms-bot:my_hs (“Ray”),
    • the virtual user @telegram_123456:my_hs (“Ray”),
    • …, and
    • the Matrix user @ray:rays_hs (“Radiator”).

I see how that would work well for incoming messages: I would be able to see which bridge each message came through, if I wanted, while keeping all the display names the same if I mostly didn’t care to see the difference.

We would need a way to make the bots know about each other. When Ray sends me a message through one bridge, we (probably) don’t want all the other bridges to send him copies of it. They’re all “my” bots running against my Matrix home server (HS), so I could add something to their configs easily enough. Alternatively, we could define common metadata that they could each set, so they could detect the situation automatically. The latter would be more flexible, in case some of them are not configured directly alongside my HS.

What about when I send messages to Ray? If I just type without a mention, then the same applies as I said before: some way of configuring in advance which bridge(s) is/are to send it.

When I Mention Ray, there are different matrix usernames I might mention, depending how I do it: if I click on one of the received msgs, I might select a bridge username that isn’t the currently configured preferred send method; how should that all work?

Maybe bridged usernames should be specially treated: all treated as something like aliases, and all resolved to the same single “real” matrix username?

Needs more thought.

MSC2346: Bridge information state event

As part of a solution, we will need a mechanism to allow multiple bridges in a room to communicate with each other. This proposal may achieve it:

Going to build a Matrix

by

2020-02-05

16:29

Leave a comment on Going to build a Matrix

Interweb, politics, software, software design

I am leaving my latest job and moving on to my new passion, Matrix.

Recently I have become passionate about the need for modern communications systems that are Open in the sense of freedom to talk to anyone. The currently dominant silos like WhatsApp only let me talk to the friends who are willing and able to subscribe to that company’s terms and restrictions, with no way to get around them when they decide to display advertising to me or stop supporting my mother’s not-terribly-old iPhone. To me, that is like some historical feudal system in which I live as a tenant and I must obtain agreement from the lord of the estate if I want to invite any of my friends to visit me. We need and deserve better than that: an Open way to communicate to our friends and business contacts. Email served that role for the first part of the 21st century, and Matrix now serves that role for the era of instant messaging.

My software development in recent years has been mostly on the open source Subversion version-control system, and I have particularly enjoyed helping to create something so widely used and appreciated. Nowadays its popularity is eclipsed by Git in small to medium sized projects, while Subversion still enjoys a strong following in certain fields such as games development due to its strengths in versioning large data sets and simplicity of usage. Participating in the development of Open Source software has given me the greatest satisfaction in my professional life, and I intend to keep it that way. That is why developing the Matrix communication system is so exciting.

p.s. I am still contracting on Subversion support work, so get in touch if you need any bug fixing or problem diagnosis.

From Open Source to Open Communication

by

2019-05-15

09:05

Leave a comment on From Open Source to Open Communication

Interweb

,

I just got around to reading mhoye’s article The Evolution Of Open and it challenged and changed my perspective in a good way, relevant to how Matrix fits in to the quest for “open” communications systems for the benefit of society as a whole.

I was focused on decentralization tech, empowering users to technically control their identity (see: “Self-Sovereign Identity“) as the primary need to concentrate on.

After reading that post, I’m seeing how empowering users needs to be at a much more social level, having communities that can technically communicate with anyone but practically need to set loose boundaries in variety of ways, having the personal and collective ability to “tune out” messages and people and entire communities that are abusive or just uninteresting to them.

It’s not that we shouldn’t all be open to hearing view from people who are different from us, it’s that if we allow everyone on the planet to shout into our ears at an equal volume, that’s not effective communication, it’s no use at all. (And spammers use spam bots to amplify their unwanted inputs.) Rather, we need ways to go selectively and occasionally to hear different views, moderated by people we trust.

In the #synchronicity channel the Matrix founder Matthew expressed reservations about how, in the article, federated systems are positioned as detrimental to providing a safe “open space” for all participants to be free from online abuses. The author writes, “I believe that federated infrastructure – that is, a focus on distributed and resilient services – is a poor substitute for an accountable infrastructure that prioritizes a distributed and healthy community”. Matthew countered that federated systems “have an existential reason to fix” that problem. Big-corp silos have financial reasons to address the problems of safe inclusion, and indeed have “health” and “reputation” teams dedicated to it, but they are only ever going to do so in profitable ways, which could be insidiously worse. Maybe the perspective expressed was what’s available today rather than future-looking. Today, the “best” moderation is achieved in some profitable silos. For the future, it seems obvious to me that federation is part of the solution, even though it poses challenges, and that point seems to be missed.

After reading and pondering these issues, I raise the priority of my ability as a user to control the rules that my federated messaging server applies to me, and to migrate to one that suits me better, above the technical ability to run my own instance of such a server.

Hoping Mozilla Embraces Matrix for Chat

by

2019-05-10

17:34

Leave a comment on Hoping Mozilla Embraces Matrix for Chat

Interweb

, ,

Mozilla, bastion of the Open Internet, intends to switch its communications from the ancient and very open IRC, to … well, something better, as Mike Hoye explains in the articles Synchronous Text and Goals And Constraints.

My concern is that the first article suggests an intention to look for a complete packaged solution — “We are not rolling our own”. it reads to me like the hope is that not only is the software packaged, but also a hosting service and also the management of the service, and that brings to my mind such things as the handling of complaints and legal bureaucracy. Such a solution is likely to be commercial and closed, because commerce has found there is a great demand for such systems and developed some.

The state of open communication systems is fragmented and rough-edged in comparison, even though great progress has been made on some fronts. Perhaps open communication systems are under-valued by the governments, universities and open-source organizations that might have power to resource their development. They might see that email works very well and many other channels are available and think that the commercial market is doing a good job in developing new alternatives and doing society a favour in making them available for use for no charge. Perhaps the decision makers have not the background, the insight and the careful consideration it takes to be able to see the other side of the equation. Anyway, the result is that the development of open systems hasn’t really been pushed by larger society, and it seems to me only now in the last few years are we (society) starting to understand an inkling what we are missing because of that.

As someone who feels aligned with Mozilla’s view of the social values and ethics of an open internet, I have been quietly wishing that they and other organizations will increasingly help push open systems into the mainstream. The possibility of them adopting a proprietary communication system quite upsets me.

I admire the foresight of the French government for boldly choosing Matrix for their chat system.

I took the opportunity to drop some hints in this direction in my response today to Mozilla’s “Reimagine the Web” Survey.

The specific issue of replacing Mozilla’s main real-time communication network is being discussed in a room/channel named Synchronicity on Matrix and on IRC, and they plan to start standing up candidate solutions and evaluating them soon. I don’t have much available hobby time to participate, but I hope to throw a few tuits into that space if I can.