An article about Building the Self-Agency Mobile Ecosystem: Push Messaging
Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently. But Who Cares Who Delivers Our Notifications? Our answer is: we care, and we do not like being locked in to depending on one mega-corp's system.
Therefore, in our libre mobile computing devices, we require a push-messaging infrastructure built from open standard technology that gives us freedom to choose our service providers and authority over them.
Should we consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa?
Not necessarily, and I will attempt to explain why.
In our family we look after our own photos — we don't want Google or any other company deciding what we can and can't do with them.
In the past we used various desktop/laptop based open source viewer software, with storage on local disks. More recently we have been running the awesome open source PhotoPrism, with its smartphone-compatible web interface and photo library management features. Although PhotoPrism is impressive judged on its own merits, and has indeed allowed us to manage our photos ourselves, it's just not quite as usable as we'd wish.
I recently learned something new about those tweety birds we hear in the tall trees all along our school run, cycling or walking past the golf course. Near the school end, lots of coal tits, a name with which I was barely familiar. Near our end, lots of wrens. I had an idea that wrens were rare and secretive and tiny, so it had not occurred to me they were responsible for that noisy cheerful chatter. Perhaps it's hard to spot one but they're loudly singing.
These I learnt last week helped by an app named “whoBIRD” which, as you may guess, listens for bird calls and displays the most likely matches. It's delightful to identify real birds, and surprisingly successful if they're not too far away.
Under Moderation, there are subsections for the main work areas of the project: Draupnir+Pantalaimon, Disclosure of Identity Attributes, and Civilised Discourse.
That last area is the one I am currently working on.
One of matrix's key properties is decentralised communication.
No single party controls the whole system, there is not a single service provider of whom everybody is a customer, anyone can choose who provides their service or run it themself.
When I install a Matrix client app, I expect it to connect to my Matrix server. What happens currently: most matrix client apps invite me to connect to one particular de-facto “central” server called “matrix.org”. As a user, connecting to my own server is a chore. In Element's flagship “Element X” preview, for example, currently I have to choose the less obvious buttons to skip past screens inviting me to choose the “matrix.org” server, twice, and input my server's domain on a “search” screen separate from where I enter my “username”.
What matrix client apps should do: discover my local server automatically, make a reasonable suggestion for my username (e.g. from my computer's or phone's user account details, address-book, etc.), and move on to asking me for my password.
It would be nice if we could standardise a way for a local matrix homeserver to advertise itself on the local network, and for a client to detect the local homeserver(s) automatically. Home media servers do this, and some other kinds of home servers. Technically there are a few different ways to achieve Zero-configuration networking, like UPnP, mDNS, DNS-SD.
A different and complementary approach is to integrate with the accounts already configured in the phone's settings (on Android for example). I should be able to configure one matrix account in one place, and then any matrix client app I install should pick up the settings from there.
Which technique(s) we use is not as important as that it should Just Work, for ordinary low-tech people who have not set up their own infrastructure but are perhaps subscribing to a matrix server provider.
(Traditional “enterprise” deployment techniques are still valid in an enterprise setting, for example where the enterprise IT department configures the employees' devices. But that is something they have the resources to develop and deploy. I am interested in what we can do for ordinary individuals at home.)
It seems to me that's the way things should Just Work, everywhere from homes to enterprises, if we care about decentralisation.
