Matrix Big Issues

I’d be very interested to see the team’s list of Big Issues. Here’s mine.

(As someone who runs my own homeserver but otherwise not closely involved with Matrix development. A very sketchy first draft, totally uncomprehensive and unauthoritative.)

Kill off (the server)

The existence of a “central” or “default” server works utterly against the goal of a decentralized system. Some important benefits are obtained from it in the short term, such as building an initial community and real-life testing of the server. However, to ensure the community prioritizes solving the problems of decentralization, there needs to be a goal of killing it off.

Some specific issues:

  • identity decoupling
    • Matrix spec issues: Decentralised user accounts #915 and others referenced from it.
    • I should be able to create an identity that is not tied to a particular homeserver, as that server may not remain suitable for my use, or even survive at all, for as long as I want my identity. The most obvious alternative would be to have my identity tied to a DNS name. DNS is a global identity system on which I can register and control an address, and set up automatic responses to arbitrary queries to that address.
    • Portable identity: Having let one homeserver handle the “account” for my identity, I need to be able to transfer that account to another homeserver. And not just directly; I need to be able to make a backup of that account, and upload that backup to a new homeserver if the previous one becomes unusable.
  •  homeserver discovery
    • Matrix spec issue: Consider options for discovering homeservers on a local network #1444
    • A matrix client should be able to discover a local homeserver when a user is not logged in and has not given a user-id. The client should suggest that the user can register or log in to that homeserver(s) by default instead of
    • To be effective, need to standardize across Matrix ecosystem a mechanism for configuring something on the local network, using maybe DNS-SD or zeroconf/bonjour, to advertise the local homeserver(s).
    • (With Riot-web, local site admin can easily provide it hosted on their own domain and customized to prefer their own homeserver. But for traditional clients distributed via app stores etc that’s not possible.)
    • Note that a “local” homeserver need not be running on a local machine: in many cases it would be running as SaaS somewhere else, but using the domain name of the local network, with the existing .well-known and/or DNS SRV mechanisms to locate it.

URLs for Matrix entities

Matrix spec issue: Do we want to specify a matrix:// URI scheme for rooms? (SPEC-5) #455

It should be possible to address any Matrix user (like “mailto:”), room (to view or join the room), and message (to view a certain message in the channel history) using some sort of URL (or URI or similar).

The scheme MUST identify the entity, at least these:

  • user
  • room
  • message

The scheme MUST provide some way for the entity to be found by Matrix-aware client software, and SHOULD also provide for the entity to be found and displayed by non-aware client software such as a generic web browser.

The scheme SHOULD support requesting an action on the entity.

  • the actioning software would not be obliged to support all actions and should fall back to simply “finding” and displaying some interface to the given entity;
  • examples:
    • join a given room as “myself” (if user following the link is already logged in to Matrix)
    • view a given room’s history
    • send a given message (to given user/room)
    • start composing a new message (to given user/room)
    • invite a given user to join a given room
    • invite the (unspecified) actioning user to register to join a given room
    • invite (given/actioning) user to start a new conversation with given originator

AFAIK such a scheme is in very early “ideas” stage.“, a clumsy work-around, gives some idea of the “problem space”.


It’s important to have a glossy, popular, widely available client app that competes directly with the likes of WhatsApp and Slack.

  • Looks to me like Riot’s 98% done and has sufficient momentum. Success!

A Non-Messenger Application

To ensure Matrix does not get stuck as just an instant messenger, there should be a concerted effort to have at least one other application domain well served.

For comparison, see how email has evolved into a system that is only really suitable for human-readable messages. It could alternatively have evolved into a system in which automated responders are common and well supported. A few examples exist, for example the “mailman” mailing list server responds automatically to a few simple command messages, but that is far from a world where users routinely plug automation apps in to their email accounts.

Message Format (Mark-Up, etc.)

I am not sure what Matrix messaging should be doing with regard to message formatting.

I’m concerned about the state of mark-up in software systems in general. It’s so …

  • fragmented: umpteen different markup formats at different levels of capability. Every word processor, wiki, instant messaging system, has its own variant. HTML, Open Document, variants of markdown, and mostly unspecified proprietary.
  • incompatible: many systems have partial compatibility at a trivial level (like bold and italics) while completely incompatible at higher levels (e.g. displaying a table, or linking sub-pages into a main page)
  • many conversions, e.g. implemented when you copy and paste, attempt to perform a conversion but exactly what they do is partial, undocumented and unpredictable.
  • open-ended: HTML for example, no limit to the richness it can express, but in the same way it does not express much semantics itself, it is a lower level formatting system, despite the “semantic” emphasis of HTML5. At the same time there are limits to the HTML richness the system will heed, but the limits are seldom stated.

In Matrix / Riot, we seem to have in each message a “plain text” and a “formatted text”, much like email containing both plain text and HTML. In email, we see huge variation in the quality of conversion between plain and HTML, usually poor, and sometimes a plain text that says “If you see this please check the web version instead”.


Svn WC & repo should share a Changes API

The WC’s main job is to compose a new revision.

While the WC also supports merge conflict resolution, a mixed-revision base state, commit of selected parts, and many other additional features, the fundamental purpose of the WC is to help the user prepare, review and commit a set of changes which will create a new revision in the repository.

On the repository side is a similar but simpler mechanism. The FS “transaction” API, designed for programmatic rather than human users, allows the system to prepare and commit a set of changes built upon an existing revision, and commit the result as a new revision.

It is really quite important that WC modifications and FS transactions have exactly compatible semantics for the changes that they represent.

It is really quite important for the feasibility of writing higher level code such as shelving, that WC modifications can be read and written by a common, abstract, interface. That is, an interface definition which enables a ‘copy’ function to plug an input interface to an output interface and push all the changes through the pipe.

To better support these needs, changes in the WC should share an API with changes in the repository.

  • WC mods API := (basic changes API) + (lots of WC-specific API)
  • FS txn API := (basic changes API) + (some FS-specific API)

Is this such a crazy idea?

There are two levels at which we can perform this API refactoring. First, streamy changes via the delta editor API. The repository side already has a commit editor for input and a ‘replay’ edit-driver for output of the changes in one revision. The WC already has a commit edit-driver for output, but no editor for receiving modifications. It needs one.

Second, underneath the delta editor APIs on the FS side is a random-access API for reading and writing the modifications in a transaction: ‘txn_vtable_t’. On the WC side we should be able to use the same API as a base, minus the few FS-specific bits, and extended with lots of WC-specific features.

The common APIs for basic changes could be:

  • basic changes API (streamy): delta-editor.
  • basic changes API (random-access): most of root_vtable_t.

Also the WC base layer corresponds to the base revision of a FS transaction, again with a lot of WC-specific extensions. Again, common APIs should be used as the base API for reading and writing that base, extended by a WC-specific companion API. In the FS API, the same vtable is used for a rev-root as for a txn-root; each method that does not make sense on a revision returns an error at run-time. In the WC, the base layer is modifiable, albeit with its own semantics.

The common APIs for the WC base layer and the FS txn base revision could be:

  • basic base-layer API (random-access): most of root_vtable_t.

There are more parts to talk about: streamy base-layer creation (‘checkout’), WC-shape/layout/viewspec API, and so on, but let’s start here.

WC streamy input/output editor APIs

  • WC replay delta
    • drives a delta-editor, like ‘commit’ does
    • thin wrapper around ‘harvest_committables’ and ‘svn_client__do_commit’
    • will be used for ‘shelve’
  • WC replay wc metadata
    • transmits WC-specific local-mods metadata
    • a streamy companion to wc-replay-delta
  • WC delta editor
    • receives and applies modifications into the WC local-mods
    • expects unmodified WC states: no merging except trivial A-or-B merges
    • write from scratch
    • will be used for ‘unshelve’
    • use it for all existing WC modification ops (‘svn add’, ‘svn propset’, etc.)
    • what special features does it need, that existing ops expect?
    • add those features in wrappers where possible, else internally
  • WC-specific metadata editor
    • applies WC-specific local-mods metadata
    • a streamy companion to WC delta editor

Definition of WC-specific local-mods metadata API:

  • includes: conflicts, missing/obstructed, …

I am starting with this streamy I/O layer because I can use it to improve shelving.

The “WC replay delta” is simple and about ready to commit. Implementation of the “WC delta editor” is in progress. I will now look into designing the streamy WC metadata APIs.

The Searchable Shop

Tried on-line supermarket shopping? It often takes me longer than real-life shopping, in terms of finding things. It’s great to be able to do it at all, but the product search interface is terrible. Imagine how much better it could be.

Let’s remind ourselves what it’s like walking into a current on-line supermarket to buy some sugar.

Dear shop assistant, I want to buy some sugar. You are holding up in front of me a long list of little boxes, each containing one bag of sugar, in an order that looks to me more or less random but you claim is “relevance”. Relevant to whom?, I wonder, beginning to feel you don’t understand me. Ah, there near the top is the own-brand white granulated sugar. That’s quite likely what I’ll choose. But no, that’s such a small pack. Do you have a bigger one? I beg your pardon, did you say I have to keep scrolling through the whole list and searching with my eyes to see if I can spot any other sizes that match the same description? Oh, please, won’t you just tell me?

If I were in the real shop, looking at the shelves, I would find the same products laid out sensibly: major groups from left to right, the basic cheap varieties towards the bottom, the expensive and wacky varieties at the top, and for each product type and brand the different pack sizes are next to each other.

How about showing me a photo of the real shop? I could point to what I want more quickly than searching through your list of little boxes.

Let’s try virtually walking in to the (fictional) Dyson-Apple-Google On-Line Grocery Shop.

Dear shop assistant, I want to buy some sugar. You are holding up in front of me a huge picture that looks rather like the shelves in your real shop. On the left I see the white sugars, then a column of brown sugars, then of alternative sweeteners. Towards the bottom are basic cheap varieties, and higher up I can see some wacky and expensive ones, and it looks like I would see more of those if I were to pull the picture further down. Niche products like those are in little boxes, but today I want ordinary sugar so my eyes focus on the products that occupy a larger shelf space. There! A huge bag of the own-brand white granulated sugar standing at the back of the shelf, with one of each of the smaller sizes standing in front of it. The label tells me the price per bag and per kilogram for a typical 1.5-kg bag as well as for the biggest and smallest sizes.

Today I want to order a big bag, as I won’t have to carry it home myself, so I click on the back of the shelf. The whole display changes, subtly but surely, to highlight which other brands and product lines also offer a pack size somewhere in the region of the one I selected. Maybe there is a less popular variety that I’d be interested in choosing instead. With a quick glance, I can see two alternatives. One is emphasizing it’s Fairtrade, in contrast to the product I have selected, and the other emphasizes that it’s British, both characteristics that I support in my buying choices; maybe the system has noticed that. The colour-banded price-per-kg indicators are showing me that one is considerably dearer than the own-brand while the other is only a little more.

Sold. Easy decision.

I know that developing that kind of shopping software is a lot of work. You can’t just tweak the existing little-boxes software. But, dear on-line shop assistant, that’s the kind of shop I would like to shop at.

What would I like to see in Thunderbird?

Mozilla Thunderbird, for my needs, is one of only two viable open-source email clients — the other being Evolution — but it has woeful shortcomings. I have been wanting to express my thoughts on what is most important.

Now I am pleased to see Thunderbird’s new Community Manager Ryan Sipes is considering a new future for thunderbird and running a quick poll to “get an idea of where folks are at”. This is the answer I submitted to the main question, “What would you like to see in Thunderbird?”

In priority order:

  1. Proper first-class “conversation view”. Existing plug-ins and options get somewhere towards it but aren’t nearly close enough relative to the bugginess they add.
  2. Drastically clean up the UI, especially all the different search activation UIs (menu, toolbar, “quick filter”) and all the different search results displays that all look and behave infuriatingly differently.
  3. Address book: separation of UI & storage. API: use CardDAV. UI: use CardBook. Storage: assume an external server as the preferred option for most modern situations; support a local store option for “traditional” self-contained installations where TB is the user’s only mail client.
  4. Calendar: separation of UI & storage. API: use CalDAV. (Same considerations as for Address book.)
  5. Message Filters: separation of UI & storage/service. API: use Sieve. UI: look at “Sieve Message Filters” plug-in for a basic example. Only a few open-source-y providers (e.g. FastMail) seem to be offering Sieve so far, so a local filtering service is probably going to be the more common option for now.

We should be facilitating and encouraging the use of open APIs for services such as address book, calendar and filtering.

I also think partitioning these services from the main program is an important part of preparing Thunderbird to be more portable to different environments, especially mobile.

Subversion Hackathon 2017

in Aachen, Germany

Today I am going to meet up with other Subversion developers to hack, talk, invent, fix, inspire.

For those who are volunteer contributors, who may have little time to devote to Subversion usually, the hackathon provides a few days to concentrate on their favourite improvements and fixes, and to bring their ideas together.

For me, employed by Assembla to improve Subversion’s support for modern cloud work flows, this gives me a chance to gather ideas from other developers, bounce my ideas off them and see where they lead, and find new inspirations and enthusiasm.

Shelving and Checkpointing is my focus right now — the ability to quickly save and restore work in progress, without having to commit it to the repository. My initial version of shelving was merged to trunk last week, and Assembla is helping to make it available for users to try. (Download it here — and please let us know what you want it to become.)

Now I have started on checkpointing, discussing the design on the dev mailing list and implementing it on the ‘shelve-checkpoint’ branch. One of the next bits of coding, that I may try to complete during the hackathon, is when restoring or ‘unshelving’ a saved change to make Subversion first check whether any of the files it will touch is already modified in the working copy, so it can warn me that applying the saved changes may conflict.

More important, though, is to come up with longer term directions. One high on my list is the ability to send a locally prepared change to a code review system, and later to commit a change that has been reviewed, like the popular ‘merge request’ or ‘pull request’ work flows. Systems built on top of Subversion including RhodeCode, Rietveld, and Assembla provide these merge-request work flows. What we have now is the opportunity to streamline and standardize how these work, making them more generally available and interoperable.


I wonder how my list of topics will have changed by the end of the week.

Sandstorm & Giftr: Sharing among a Group

“Giftr” is an extremely simple gift-list app: I write a list of things I want, share it with other people (my family, friends), and the other people in my group can add comments that all of them can see but I can’t see. Each person in the group can similarly write their own list.

The author released it as a Sandstorm app. Sandstorm handles user identities, login, and sharing of “grains” of data. A grain is a smallish unit of my data, such as a photo album, managed by exactly one app, that I might or might not share. Sharing means giving another user access to my grain, and that access could be anything from full privileges to add, edit and delete data (photos, metadata, etc.) or any lesser level of access such as just commenting on existing photos. What levels of shared access are offered depends on how the app has been programmed.

As a demo app for Sandstorm, Giftr doesn’t work in the right way. It creates a grain (my grain, owned by me) which it calls a “Giftr group”, which not only holds my list but also invites the other members of my group to create their lists inside it, inside my grain.

Instead, when Giftr invites the friend (with whom I shared my grain containing my list) to create their own list, it should create it in a new grain that they will own, and reciprocally share access to that grain back to me.

Furthermore, if I have already shared with a group (more people than just that friend), the new grain should automatically be shared with the same group of people, in order to make joining the group work in the same easy way that it currently works inside Giftr.

Now, this is where I wonder if Sandstorm needs to add support for sharing to a group, or if enough mechanism is available that it could be programmed within the app. It depends on exactly what we mean by “a group”. My grain may be able to tell the friend’s new grain the set of people to whom my grain has been directly shared, at this moment. But the way we expect a group to behave is that when we invite a new member to join the group, all members will be equally linked. The group membership list must therefore be agreed between all members, so either the membership list is a single distinct object (perhaps owned by one member, perhaps not) or the members each keep their own membership list and have a way to synchronize. This surely is a well known general problem in computer science, with well known solutions.

Does Sandstorm already have something, or if not then what solutions could fit into Sandstorm?

Too Many Password Managers

First I had too many passwords. (And still do.) But on top of that I now have too many password managers.

My web browser, Firefox, remembers web site passwords for me, which is very helpful indeed. (On a Mac, Safari does that too and additionally offers to generate random passwords for new sites, which is even better.)

I use KeePassX as my primary password manager. As well as username and password and web site URL, I find it useful to store the associated email address and some notes, e.g. “Dormant account: I requested to close it on 2016-01-01 but sign-in still works on 2017-01-01” or “Tried to update to my new email address on 2017-01-01 but the site refused: need to contact customer support”.

Thirdly, my operating system Ubuntu has its own “Passwords and Keys” app which stores passwords and keys on behalf of other applications.


  • it’s a nuisance having to copy data between them (Firefox <-> KeePassX) when creating or changing a password
  • backup is complicated: I hardly know where all three stores are, or whether they are all uniformly backed up
  • three different master passwords to manage (no, don’t suggest what you’re thinking :-), and not being sure whether all three stores are similarly and sufficiently secured

Can I please have fewer password managers? OK I chose to add KeePassX into the mix, but Firefox forced its own one on me whereas I would like it to use either the operating system’s password manager or one that I designate.

Click “Edit the Source Code”

How Open is the Source?

Each time I want to modify or fix some open-source application that I’m using in Ubuntu, it takes me a long time to find the correct source code, download and unpack it, install required dependencies, and figure out how to build and run it. I usually use either Ubuntu Software or Synaptic package manager to install an app, so can I also use those to install its source code? No, I can’t. I haven’t fully learnt to take advantage of the tools that are available to automate parts of this process, and I should. But nevertheless…

This is how easy it should be for anyone to modify an open-source software application on an open-source OS:

  • While running the app, click “Edit the Source Code”. (This button appears in the launcher, perhaps, when it is available.)
  • Ubuntu downloads the source code and runs an IDE with the source code loaded.
  • At this point, I can edit the source code if I wish.
  • The IDE is configured so that clicking its “Build” button re-builds the software, and clicking its “Run” button runs the built version in place of (or alongside) the system-installed version.

The key is zero configuration effort for the user to get to this point: running the locally built version.

The power user will want to configure the choice of IDE and other details, but that’s secondary.