In a discussion room about the Fediverse, bkil drew my attention to “The age of average” by Alex Murrell, and questions whether like cars, cities and coffee shops, all social media posts should end up looking the same. Why not let the senders and recipients style them?
Should we not expect and enjoy seeing messages or “posts” reflecting the creative expression of the different individuals and groups we interact with — our friends, family, colleagues, employers?
Yes, yes, YES! I've been thinking the same for Matrix, and it applies of course equally to the (ActivityPub) Fediverse too. But it's so “radical” to many people's ears today, accustomed to the strictly limited silo offerings from Big Tech.
I think the way I would explain is with Real World analogies like this: When I hear from my friend D, it's usually a picture-postcard and their writing is scrawly and fills all the space including the margins. When I hear from my friend E, it's usually a tidy note on posh quality off-white paper, with their logo in the corner.
I would LOVE to be able to receive the same richness in indie social protocols, for more than just aesthetic reasons.
I would love to work for or with Murena on their /e/-OS phone. UnifiedPush support is one of the first things I would propose to do.
UnifiedPush is in my humble opinion one of the most important recent developments for freedom phones. It grants us freedom from Google’s near monopoly push notification system FCM. I have followed the development of UnifiedPush it from its OpenPush origins.
What have I done so far?
I have deployed ‘ntfy’, a UnifiedPush compatible server implementation, on my home network. I documented and published my installation script (which uses Ansible and Docker), and successfully submitted it for inclusion in the popular Matrix installer matrix-docker-ansible-deploy, so matrix self-hosters can deploy it easily.
My self-hosted push service now serves notifications to several of the apps I use.
If given the chance to advance UnifiedPush support, I would propose a plan something like this:
deploying a UP server for /e/ users (one for the Murena central server, and one in each self-hosted deployment), initially choosing one of the existing kinds of UP server (probably NextPush because obviously it's built to fit into nextcloud);
creating a UP distributor as an /e/-OS system app, by adapting an existing one (NextPush, to match the server), and making it auto-discover/configure the server from the /e/-OS account info;
working with important client apps (/e/-OS default apps first) to add support to them;
perhaps tweaking the U.P. server and distributor to better suit this use case, if and when needed.
In practice, what do ninety-something percent of small FOSS projects do? They sign up on Microsoft Github. If we are one of these, then we feel our little project has a home on the Internet, its own address: https://github.com/our-name/our-repo. Oops, but did I say an address of its own? Well, there's the catch. I meant an address of Microsoft's own.
Github is a Gatekeeper. Every link to our project now takes the reader through a virtual gateway owned and ruled by Github's owner, Microsoft. The domain name is the gate, and its owner holds the key. Want to visit the source code? Before we reach our-name/our-repo we must walk through their gate at github.com. We must pass through whatever they put in the gateway. Ads? Nagging to sign up? Then they will let us visit the source code that we feel is “ours”.
The famous inventor Zangemann lives in a huge villa high above the city. Adults and children alike love his inventions and are desperate to have them. But then... the inventor makes a momentous decision... The clever girl Ada sees through what is going on. Together with her friends, she forges a plan...
Ada begins to experiment with hardware and software, and in the process realises how crucial it is for her and others to control technology.
Decentralised linking from the Web (HTTP contexts) to a matrix user or room.
Status: This is a proposed, draft specification for consideration by the matrix development community. This version was initially posted before any discussion or feedback.
Matrix is supposed to be a decentralised protocol [MATRIX]. While much of it is, an important part isn’t. Matrix uses matrix.to [SPEC-TO] as a centralised mechanism for linking and invitation to matrix resources from HTTP contexts.
We can do better than centralised.
This is a proposal to fix an important part of that problem.
Resources around development of camera apps, camera API standards, and photos management, in Indie Phones, degoogled Android, Murena /e/-OS, Purism Librem, etc.
With sustained dedication from their producers working with very limited budgets, these alternatives are coming along nicely and by now are certainly usable. Understandably, however, they are not yet as slick as those funded (and controlled) by the mega-corps Apple and Google.
There is much more to be done to bring the indie phones up to a level of sophistication that ordinary people find a pleasure to use and to trust. In this article I look at one rather technical aspect of it: what developments do we need on the infra side?
These are some of the talks I'm most interested in, at FOSDEM '23.
I won't be there in person, I'll be watching some from home and in the matrix.
By Tracks or Dev Rooms | Times are UTC+1
Special Extras
Sat 18:00Book reading: Ada & Zangemann – A Tale of Software, Skateboards, and Raspberry Ice Cream — “In this hopeful story Ada and her friends join a movement that started back in 1983. Their courageous adventure of software freedom and learning how technology works is a wonderful way to introduce young people everywhere to the joys of tinkering!” —Zoë Kooyman, Executive Director, Free Software Foundation
Sat 14:00Linux Inlaws — A how-to on world domination by accident — the story of this podcast and its tech stack
Sun 12:00Rosegarden: A Slumbering Giant — How a 20-year old OSS project is still going strong — music composition and score software
Sun 12:00Practical Computerized Home Automation — “Home automation is an elusive technology — often desired, rarely achieved. This talk explores a successful ten-year home automation deployment, outlining the challenges that derail many attempts. It will cover technology choices, programing basics, and a dozen successful applications.”
