Tag: self-hosting

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.]