By using a silo we exclude children

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

Matrix — Why?

A collection of articles

Dear politicians of the EU, it’s time to decentralize the internet” with a fun video 600 TOMATOES explain how to fight BIG TECH introducing federated inter-operable messaging — NoordStar, 2021

WhatsApp and the domestication of users with case studies Mozilla, Signal; followed by Keeping platforms open with case studies XMPP, Matrix — Seirdy, 2021

We Need Alternatives to Big Tech. These Decentralized Tools Might Be The Answer. highlights Beaker/Hypercore and Matrix — New America, 2021

Best WhatsApp alternatives that respect your privacy — Matrix is the only one which allows users/groups to control their own servers/services — ProtonMail, 2021

Matrix for …

Up-Scaling Infrastructures for Open ScienceGeneration R

Matrix needs: Bring Your Own Domain

Owning Your Identity in matrix is currently not as cheap and easy as it should be. Hopefully this will be changing in the not too distant future.

The current options for using your own identity in Matrix are, roughly speaking:

  • rent a personal matrix homeserver as a managed service “in the cloud”
    • around £1 a month for your own domain name, plus
    • around £10 a month for the matrix service
  • run your own server
    • around £1 a month for your own domain name; plus
    • rent a virtual server from under £5 a month, or provide your own; plus
    • your skill and time

The sticking point is that currently you have to run a whole matrix “homeserver” for each DNS domain name that you want to use in a matrix user id. To register an account on the matrix.org server, for example, you must use an identifier like @some-name:matrix.org which is an identifier owned by matrix.org. There is no option to Bring Your Own Domain and register yourself as @myself:myself.org on that server.

The one domain per server model works well where the users are already members of an organisation with its own domain name, such as a government, a school or a business. For the ordinary individual who wants to own their own online identity by bringing their own domain name, however, the requirement to run their own matrix homeserver is currently too onerous.

The need for one (virtual) server per domain is a limitation of the current server software. It could be lifted in future. Then we could see commercial services offering Bring Your Own Domain accounts on their servers. This would be cheaper to run than a server per domain, and would bring a useful hybrid model of:

  • terms and conditions set by the service provider; with
  • self-ownership of one’s matrix account’s identity, giving the ability to move one’s account to another service provider with different TOCs, (or, in the extreme, self-hosting) without any loss of service or contacts

The matrix community needs to break that barrier somehow. Options include:

  • making tiny simple homeservers so it’s no burden for each user to run their own;
    • needed also for p2p Matrix, and beginning to happen with Dendrite
  • making homeservers that offer a Bring Your Own Domain option.

Besides Dendrite, the Matrix community has some other small-footprint homeservers under development which may be ready for use within the next year or so. I hope we will see Bring Your Own Domain (aka multi-tenant) capability being developed in at least one of this new generation of homeservers.

The good news is the options are looking likely to open up. The crucial fact is that you can own your identity in matrix, already.

Related:

Matrix: Understand Data Deletion for SysAdmins

Deletion is an interesting subject. It’s not as simple as “either it’s deleted or it isn’t”. Matrix is distributed. In order to reason correctly about this stuff we need to understand the different kinds of deletion in principle, as well as how they are implemented in matrix in practice.

This blog post does not (yet) provide a complete answer.

Continue reading “Matrix: Understand Data Deletion for SysAdmins”

Decoupling Identity in 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.]

Improving Matrix.to Links

Sharing links to Matrix users or rooms or messages is broken. The “matrix.to” service currently does not “cut it” for federated use.

A standard matrix: URI scheme is proposed as a superior solution, but that is far from ready and we need a usable interim solution.

Where are we with having links like https://matrix.to/#/@nukeador:mozilla.org to suggest chat.mozilla.org? …

Rubén Martín (nukeador)

To make this interim matrix.to service work satisfactorily with a federated matrix network, while it lives at a centralized URL, we need to make it support decentralized use cases as far as possible.

Current problems

Problems, in terms of design issues:

  • users can’t customize it
    • e.g. hide unwanted options, add custom options, set a default
  • federated server admins can’t customize it
    • e.g. completely replace it, or customizations as for user
  • always points to riot.im
    • should point to user’s or federated server’s preferred Riot-like web client
  • can’t click through to any other client the user has installed
    • where client registered a URI scheme handler on the device
  • doesn’t remember the user’s choice and get out of their way
    • it could redirect automatically on future visits
  • the UI is not simple, clean, helpful
  • doesn’t offer the proposed standard matrix: URI scheme
    • should offer matrix: scheme links, initially as an advanced option, for those who are starting to test or use them

Many of these issues can be improved by changes to the central “matrix.to” web site.

I propose the following changes to the matrix.to service:

Together, these might address the most pressing of the usability issues.

(The last item, adding “matrix:” URIs, is important in a different way. Rather than solving an immediate user need, it promotes development of the matrix ecosystem towards replacing this interim system with a better one.)

One issue remains. The fact that federated server admins can’t customize the experience is hard to avoid. Some options are:

  • The page could let the user redirect to their preferred “matrix.to” replacement page, and remember the preference. That works for power users on a repeat visit, not for casual or first-time users. Better than nothing so I’m starting here.
  • The page could perform a client-local search for config settings, that’s wider scope than browser-local; some kind of Zero-configuration networking, perhaps; I haven’t looked into it.
  • An admin could set local DNS (within an organization’s internal network, or a home user’s router) to point the DNS name “matrix.to” to a local page. Only useful for users sitting on such a network; may be useful in offices etc.

Mock-ups

I am trying out these ideas. I will make source code and a demo available when I get around to it. I will update this post below, as and when I do so. I will listen to your feedback (in the Matrix room #matrix.to:matrix.org please, rather than blog comments) and incorporate your suggestions where they make sense to me.

Some early draft mock-ups:

Please join myself and others discussing this in the Matrix room #matrix.to:matrix.org .

Matrix Big Issues

A year ago I wrote up some thoughts on Matrix Big Issues. Here is another take on the medium-to-big issues that I think are important and interesting.

As you will see, these are just sketchy notes to record ideas I have been thinking about. I have not had time to research them and write them up further.

(My personal view as someone who runs my own homeserver and is getting involved with Matrix development.)

Big Issues

Matrix needs…

Easy Open Data

An ordinary user should be able to control their data (message history & media)…

  • extract their data
  • process (“re-mix”) their data offline using third-party tools
  • load their data, even if it is not a “true” history

Use cases

  • Alice and Bob register on Server-1 and exchange some messages. Server-1 goes read-only and is about to shut down. Alice uses her matrix client’s “Save to file” option to save “everything”: rooms, media, her account data, as far as the client can access it. Bob does the same but after the server has shut down, so his client can only save what it had cached. They register on Server-2 and import all their data. Everything works as well as possible.
    • Perhaps they can choose whether to import a read-only history using original identifiers tied to Server-1 (better preserving external links) or create read-write rooms (etc.) with history populated by translating to Server-2 identifiers (more disruptive to external links).

Support in popular address books [EXTERNAL-ENGAGEMENT]

  • VCARD/CARDDAV, microformats2
  • Thunderbird-CARDBOOK, Evolution, Gnome, KDE, Ubuntu-accounts,

Mobile: 1st class integration [MOBILE-UX]

  • Contacts: call/text directly from Contacts, save to Contacts
  • Contacts: get Mx support into popular Contacts apps [EXTERNAL-ENGAGEMENT]
  • Calls: make/receive just like phone calls (dedicated buttons, mute media, etc.)
  • SMS bridge: smsmatrix needs work
  • telephony bridge: should be a separate component, serving multiple Mx apps

Mark-up system (for IM class)

  • A base mark-up system with subclassing, to bridge systems that have their own mark-up sets.
  • Seek common denominators plus extensions.
  • NOT like https://github.com/tulir/matrix-doc/blob/formatting-entities/proposals/2427-json-based-message-formatting.md
  • Find that composable/pluggable news media markup system I read about a few years ago

The Public Switched Social Network (PSSN) [EXTERNAL-ENGAGEMENT]

  • Industry Co-ordination
  • see John Ryan’s presentation in: https://blog.archive.org/2020/01/30/our-social-media-is-broken-is-decentralization-the-fix/ from which (PSTN -> PSSN):
    1. Alternative operators -> alternative media operators
    2. Interconnect technology -> server-server / backend data exchanges
    3. Interconnect business agreements
    4. Data / records
    5. User equipment / experience -> new user apps / APIs
    6. Regulatory framework (and transparent ethics)

Single Sign-On (SSO) [ONBOARDING, SERVER]

  • Why? Users hate multiple logins. Self-sovereign services must flock together.
  • Especially target easy setup for private and small group installations. (Enterprises can plug in to their existing SSO.)
  • Poor state of SSO in FOSS.
  • Work with other FOSS; decouple the id provider functionality.
  • see: keycloak.org, pomerium.io, portier.github.io
  • see: self-host systems that offer SSO provider: Nextcloud? Mattermost? UBOS?

Scripting, auto-responder, filtering, web-hooks [CORE-APPS]

  • What? Allow user to program functions in their user account.
  • Why? User of a digital comms system should be empowered to control their own automation, in case they don’t want GAFAM doing it for them.
  • Why? Enterprises benefit from automation of email, SMS, webhooks, etc.; private/small groups should be able to benefit as well.
  • first class core + user plug-ins
  • Simple config; like old home computers booted up to BASIC; e.g. manual config through a bot room, scripted config by file uploads.
  • eg: look at GAFAM: respond to calendar invitations, maps
  • eg: look at enterprise customer comms: SMS to query & top-up accounts, book a ticket

In decentralizing ids: option for forwarding one’s own DNS domain to a multi-tenant server [DIDS]

  • DNS is one method for addressing/routing to my id

Sign-up [SERVER, ONBOARDING, EXTERNAL-ENGAGEMENT]

  • “install on my existing server” (NextCloud, UBOS, Sandstorm, etc.)
  • link/guide to purchasing a domain name?

The route to Matrix for an average individual needs to look more like this:

  • invited by a friend to join Matrix
  • sign up to matrix.org or another big free general-purpose server
  • find the concepts and UI easy to understand
  • after a while, want a self-sovereign id
  • choose a self-sovereign id: either own-domain DNS or another form
  • add own id to the account, setting it as the main id, setting old id to forward to new id
  • want to bridge to WhatsApp etc.; current server doesn’t allow it
  • choose another server; easily move the account, id and history to the new server

Smaller Issues

And some smaller but still important and interesting issues:

Riot: Simple UI mode [ONBOARDING]

  • (see “Idiot mode”, https://github.com/vector-im/riot-web/issues/8952 )
  • Why? New user: Child/Parent.
  • Why? New user: friend migrating from WhatsApp.
  • Why? Power user (myself) wants minimal clutter in most cases.
  • in group rooms: show minimal metadata (typing notifications, read markers, etc.)
  • in 1:1 rooms: show little metadata
  • vastly simplify Settings (not just remove; organize with modes & search)

A reference system definition for server [DEV-META]

  • for each major use case (private, group, public)

a “Why Should I?” page [ONBOARDING]

  • Why? Because I want to persuade family & friends but I’m not good at persuasion.
  • one specifically addressed to a WhatsApp user with no tech skill
  • one specifically addressed to a FOSS project/group (e.g. Apache Subversion)
  • to quote, link, copy, share

Default Widgets/Integrations/Bots should include FOSS [FOSS-ALIGNMENT]

  • I’m looking at the default integrations (Modular.im)
  • especially provide FOSS alternative to each proprietary one
  • standard calendar (vs. Google)
  • peertube (vs. Youtube)
  • GitLab bot (vs. GitHub)

Responding to a blog that was linked [DEMO-APPS]

  • using activity pub etc.

Log monitoring: Synapse reporting Synapse logs to a room [DEV-META, DEMO-APPS]

  • Suggested ~2020-01-24 by someone on -docker-ansible-deploy; I commented.

Ways to Delete Messages in a Matrix Federation?

The topic of purging obsolete/old/unwanted content is an important one for the Matrix ecosystem, as for other distributed systems. It’s not easy for developers and users to get our heads around all the desired and possible meanings of removal — from a user selectively removing items just from their own view, through servers garbage-collecting unreachable content, right up to a federation admin asking all servers in their federation to remove content and push that request out to their client apps which might honour the request.

It would be helpful if we could develop or refer to a set of descriptions of the different scenarios, that link the user’s point of view on the one hand to the system/protocol/server point of view on the other hand, with analogies to more familiar technologies like paper mail and email. Probably someone in the distributed systems world has already written this up. What would be very helpful is having some labels/terms/URIs to refer to them.

Without that, we are always going to be asking what a particular “Delete room” or “Delete user” or “Delete message” API or UI button really means. Without that, we are always going to be wrongly guessing what a user or another admin really wants to achieve.

Anybody know of such a write-up that we could borrow?

 

Goodbye G+, Hello Matrix and Indieweb

And, poof!, there goes another “walled garden”. Goodbye Google+, I won’t miss you. Rather than jump ship to another silo such as FB, I’ve been getting very interested in non-silo, “own your own digital self” alternatives, sometimes referred to as “re-decentralizing” the Internet because it originally was that way before these monoliths came to dominate it.

The website switching.social suggests “ethical, easy-to-use and privacy-conscious alternatives” to popular sites. I can agree with most of their suggestions. For blogging, there are several lightweight, Open alternatives.

To ensure you keep ownership and control of your next website or blog, there are two requirements:

  1. Connect it to your own domain name (mine’s at blog.foad.me.uk) so you don’t lose control of it and your links don’t break and addresses don’t change when you have to leave your service provider. If you pay someone (like wordpress.com) to run it, you’ll need to pay them for the privilege, as well as registering your domain name in the first place; each of these may be around £1 to £2 a month.
  2. Make sure it’s open source, so it can in practice be set up again somewhere else when your previous service provider shuts down or you need to leave them.

For how to Own your Own Data in terms of blog posts and responses, etc. — see IndieWeb.

For messaging, it’s got to be Matrix. It provides a user experience like WhatsApp and Slack but is Open, so you can choose who runs your server and how much it integrates with other services.