julian

Wanted: Digital Dreams

Mon, 08 Sep 2025 11:15:00 +0000

In this corner of my world, I seek a better digital life, one where I own my own digital identity, where I am not forced to be a microsoft or facebook user just because my school or family use them, one where I get to choose my digital service providers to suit my values...

In this corner of my world, I plan how I might achieve this using open-standard protocols, open-source software, replaceable services...

In this corner of my world, in order to get some of this digital sovereignty in my own life, and to learn skills to help build the better world, I practice “self-hosting”, but in great frustration knowing full well it's so far away from the needed solutions...

In this corner of my world, I am meeting lots of people with similar views, and hearing lots of comments like X is bad, Y is an open-standard protocol, Z is an ethical service...

But I am rarely hearing people's imagination of how it all works in this new, better world.

How does a family pick up a laptop and a tablet and a smart-phone and a printer and some on-line service providers in this new world, and get on with managing their family archives and their school work and their chats and calls and diaries? How do they transfer photos between their devices, find a document they wrote or scanned earlier, verify their human identity when needed, choose and change their messaging service providers?

A common pitfall is thinking in terms of apps. Nextcloud, Fediverse, Jitsi-meet, Matrix, Linux, open-this, libre-that. Great, those are useful components, but they are not the picture.

Do we imagine each home running a little Microsoft replacement and a compressed Google compatible service in their home router box? Do we see communities running big servers for their citizens? Do we dream of peer-to-peer local-first apps, operating independent of network services? Maybe some of these are involved, but how would it actually work from the user's point of view? How do we pay for it? In what ways can we demonstrate it working better than today's Big Tech model?

Without this imagined new way of working, we are swimming in a sea of bits of software and protocols and services and funding campaigns for the same. Without our shared vision, how will all these little bits ever come together?

Once we see the big picture, we'll enjoy plugging the little bits together into a pattern. Look! — project Z implemented this bit of the picture, so now they interoperate with all those adjacent projects. Look! — project Y needs help with solving that other bit of the picture. Look! — two incompatible protocols — we want to plug those areas together so let's do something about it.

A few times I have had a go at writing down how things work “in my dream world”. I'm not short of ideas, but it takes time and effort, I'm not so great at telling stories, and I don't have all the dreams. I want to write and share more of my own dreams, and I also want to read how it all works in your dreams. Bouncing ideas back and forth with others is stimulating. It's important. More and more I am thinking how much better we could work together if we shared these dream stories. Stories in words. Stories in pictures too.

Where are our dreams? Who will write them down, draw the big pictures, share the visions?

#ownDomain

Follow/Feedback/Contact: RSS feed · Fedi follow this blog: @julian@wrily.foad.me.uk · matrix me · Fedi follow me · email me · julian.foad.me.uk Donate: via Liberapay All posts © Julian Foad and licensed CC-BY-ND except quotes, translations, or where stated otherwise

Bye Bye Facebook

Mon, 21 Jul 2025 13:00:00 +0000

Time to shake off another Big Tech and feel that delightful breath of fresh air, health and freedom.

Pruning the old overgrowth of commercial Big Tech and letting the new shoots of indie tech flourish.

“THE JOY OF NOT BEING SOLD ANYTHING”

Facebook Status:

Deactivating Facebook prior to deleting it from my life. (Not that it was in my life anyway. Hardly touched it in ten years. But because this account existed it looked like I was here. If you thought I was here, I wasn't; Zuck's system wanted you to think that. If you thought I was receiving your kind messages and rudely ignoring you, I wasn't; Zuck's system wanted you to think that.)

I love your stories, your pictures, your news, you as friends and family. I get that Facebook provides a way for you to share these. But I don't like Zuckerberg or any overlord controlling who I'm allowed to connect with and how we are allowed to communicate.

In Facebook I don't feel comfortable. I feel pounced-upon by the Algorithm. I feel the system is dangling your pictures and stories in front of me as a lure, as bait. I feel we are being manipulated, abused for commercial gain.

And so I haven't visited Facebook club. Not for years, aside from a few occasions when I went in briefly to look for something or other. And so I haven't seen your delightful sharing of life events and interesting stories.

Mind you, I'm not the socialable type, so I maybe wouldn't go there nor post anything anyway, even if the place we're talking about was a delightful public park under ownership of the commons.

Why Disconnect?

It's a ghost account. For ten years I haven't even been looking at Facebook, let alone writing back to the friends and family who post there. I already deleted years ago the few posts and pictures that I had initially uploaded there. The only reason I kept the account so long is in case I might one day want to contact an old friend or they might want to contact me and we might not have each other's phone or email... But really, it's ridiculous, just FOMO and inertia.

I detest the feeling of being beholden to Zuck's mega-corp. What do I get from that contract? I get the sense of maintaining what to me is merely a subsidiary way to potentially contact some people. Why should I need to keep subscribing to the Facebook club and playing its game by its rules, just for that?

So it's Bye Bye Facebook.

Shall I silently close my account and slink away? I considered it, and temporarily “deactivated” my account for a few months. But before closing it for good, first I want to tell the friends how I feel, and where to find me.

Where To?

I already feel great with my de-googled phones, email at my own domain, closing my Amazon account, Giving up Github, wearing an open-source smart watch.

More about my de-googling and other freedom from Big Tech's shackles:

https://wrily.foad.me.uk/tag:degoogled

If you feel the urge to join the movement, the Opt Out Project has a fantastic set of practical guides for freeing oneself from all kinds of pervasive surveillance tech.

https://www.optoutproject.net/

See you in the Free(dom) World

... through regular web sites and blogs like my Wrily;

... through the non-proprietary digital communication tools like email, the telephone system and SMS, Jabber/XMPP, matrix, and the fediverse (the network that unites Mastodon and dozens of other software and services) — we call these protocols — that are standardised, operated by a diversity of providers, and not under a single company's control;

... and perhaps occasionally in Real Life.

p.s. A funny thought occurs to me. I can't help wondering if among my friends there are some who might consider this event “sad” or that I need some kind of “help”. If that's your reaction, I invite you to try on a different perspective.

Music By Computers

Sat, 21 Jun 2025 13:20:00 +0000

A computer program that generates music. How quaint.

I remember when I first heard computer-generated music. My father showed me a book, “Music By Computers,” and we listened to some of the recordings of music generated by various kinds of programs.

That was in the 1980s. “Music By Computers” had been published in 1969, compiled from papers presented in 1966.

“Music By Computers” at archive.org

The recordings for the book were supplied as gramophone records. Thin, floppy, playable gramophone records, tucked in to an envelope at the back of the book.

This was quaint, old technology. The recordings were already twenty years old. The music sounded like it had been made by a computer... and yet it was tolerably pleasant or entertaining music, perhaps, depending on one's expectations and level of musical sophistication.

We dabbled with making our own programs... beep-booply-beep-boop... on our modern Sinclair ZX Spectrum.

People are still playing music, and still playing with music generators. Now folks are calling their music generator programs “AI” to ride the latest hype wave...

I'm glad to see people are still having fun with the idea.

An excerpt from “Music By Computers”:

Title Music to LINK, Side 2, Band 4

This short excerpt is the background music for the title and screen credits for the short documentary film LINK produced by the Argonne National Laboratory film group [3]. The film explains the operation of a computer program LINK, written by R. K. Clark of the Applied Mathematics Division at Argonne, for use in the automatic analysis of spark chamber photographs taken during experiments in high energy physics. Since it concerns a CDC-3600 computer program and includes com¬ puter-produced animation sequences which were photographed directly from the computer cathode-ray-tube display and which illustrate the program operation, it seemed only appropriate for the computer to provide the music with which to accompany and emphasize its accomplishments. Though the selection is only a minute long, it is in fact quite complex, accurately synchronized to the film (synchronization is a trivial problem) and contains some noteworthy illustrative effects.

An excerpt from a review of “Music By Computers” by a Mr Howe in 1970:

... [This work in recent years in computer synthesis of sound] involves the work of both scientists and composers, and thus raises both technological and aesthetic considerations. For people unfamiliar with this kind of research, the discussions in the book will seem very sophisticated and advanced, and it will appear that many rather general conclusions are now beginning to emerge out of quite disparate approaches to common problems. This impression, however, does not stand up under careful investigation...

Illustrations derived from scans of the title pages of the book, accessed through archive.org. First excerpt from the same. Second excerpt from a review by Hubert S. Howe, Jr. in Perspectives of New Music Vol. 8, No. 2 (1970), pp. 151-15, accessed through JSTOR.

Caught in a Self-Sovereignty Self-Hosting Knot

Fri, 06 Jun 2025 11:13:00 +0000

I'm caught in a self-sovereignty self-hosting knot of ambition. Some days it seems everything I want to simplify or improve or upgrade is blocked by something else. I want to blog more from my WriteFreely instance, and for the time being I can, but it's bothering me that it's out of date, running on an out-of-date Yunohost-11. I'm proud to have set up staging copies of much of my infrastructure so I can try a test upgrade, but that reveals the upgrade is broken, so instead I want to migrate it either to a fresh Yunohost-12, but I discover that no longer supports exactly the same way of logging in with its SSO at my base-domain which is managed separately outside Yunohost (I'm skipping lots of details, they're beside the point here), and it reminds me WF is one of my last few “production” services still running in YNH. I want to get them out of YNH because for all its good points it's designed as a monolith, not to plug and compose with other infrastructure, so... I could migrate Writefreely instead to another hosting method outside Yunohost, like MASH, so I try that and find support for Mariadb isn't yet implemented in MASH-WriteFreely, so I could either add Mariadb support myself and then migrate the DB directly, or let it use another DB and instead try to migrate the posts and subscribers and metadata through WriteFreely's API... and so on for my other services. Ugh. I mean, I knew it would be like this. I chose this path, and I kind of like it. Sometimes I even find that software has been developed in the meantime that does indeed simplify and improve things for me, like when projects add support for SSO, and that's wonderful! But just so much still remains to do... And I'm trying to skip some of the nitty-gritty by looking ahead to better technologies: want to move infrastructure from Docker in VMs in Proxmox to mostly LXCs in Incus, eventually learn Nix and K8s, want to get involved in improving, unifying, standardising some of the best of small-medium scale hosting frameworks like Yunohost, Co-op Cloud, SelfHostBlocks/Skarabox, Fediversity. I realised at this stage any more tweaking I do to my private infra is more or less a waste, now that I've learnt from it. What matters is what I can contribute to projects that others share, so I'm aiming that way now. And thinking of some ways to “level up” this world of personal data self-sovereignty and make things that ordinary people can use, plug-and-play kit for family and friends and schools to store and easily manage their identity and data. Have (some) skills and (maybe good) ideas; lack money and time. Must get around to writing about the ideas at least. Is my WriteFreely still holding up for now? Whew.

Enter your Bossname

Thu, 15 May 2025 08:44:10 +0000

Polite software. Politeness in software is under-rated. And deference.*

Software that I truly control: you are likely FOSS/SOSS. You may call me “Boss”. (“Settings –> Boss preferences”; “Enter your bossname.”)

Command-line apps: you may call me “Commander”. (Hear me out: I'm serious beyond playing with words.)

Any system I don't control: you may refer to me as, “Esteemed client” or “Sir/Ma'am”.

Big Tech People-Farmers: you may justly call me “serf” or “chattel” (related to cattle; look it up).

Graphic meme idea: a collage of recognisable log-in screens etc., terminology edited.

* Deference, but not fawning. Looking at you, LLM chat bots.

Open Source Considered Harmful -- Choose Your Browser Wisely

Fri, 10 Jan 2025 10:57:16 +0000

Google Chrome vs. Mozilla Firefox

“It's built with open source technology — that's good, right?”

Have we lost sight of the goal posts? Why do we like open source? So we can inspect our tools, modify our tools, own our tools. The browser is a tool. But we want to own tools that serve us. Here we're talking about Chrome/Chromium, a tool built to serve its creator's interests: advertising, attention economy, centralised big tech services. Built to serve the Facebooks, the Twitters, the Tiktoks, the Amazon.coms of our world. Built to support “monetizing” us as we use it. Should we desire that tool because its creator is letting us “own” it? Is owning that particular tool good for us? Should we spend our effort debating exactly how “free” it is?

Not me. I reject it. I choose tools that are built to support public standards and for the good of the people who use them. There's currently no perfect independent public-spirited browser. The best fit for my values is presently Firefox derivatives. (That's despite Mozilla's abominable financial dependence on and consequent promotion of Google, which I deplore. At least Firefox lets us operate it in our own interests, by letting us install ad blockers, etc., and has a community of better-privacy derivatives.) Do we see Google building their browser to support local community low-tech protocols and practices, like Fediverse for example? We don't.

And we don't choose a tool just for being given away as open source, when that tool is built to serve Big Tech above ourselves.

UnifiedPush -- Wider Developments

Wed, 27 Nov 2024 14:48:00 +0000

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.

How We Get There

How can we build this? What is needed to get widespread UnifiedPush support in /e/ and other mobile OS?

The big picture involves several areas of work.

OS integration of the distributor, including how it's configured, auto-detected, optimised, etc.
Server Software: Making sure a suitable server-side component is available, supported, optimised for this use case.
Server hosting: making sure a server component is easily deployable by others, including making generic deployment methods (Debian, Docker, Nix, K8s, ...) and integrating it in some hosting systems.
Apps: Working with other apps to make sure they connect and work with UP out-of-the-box.
Sharing this work among other mobile OS projects (microG, CalyxOS, GrapheneOS, PostmarketOS, ...) .
Consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa.

(Links in this and the following sections lead to relevant issues or discussions, where I could find any.)

OS Integration of the UP Distributor

Including how the UP distributor is configured, auto-detected, optimised, Android permissions, etc.

I recently analysed how /e/OS 2.5 has started the ball rolling

Server Software

Making sure a suitable server-side component is available, supported, optimised for this use case

Nextcloud: UnifiedPush Provider — exists
It could alternatively begin with a fork of ntfy-server for example.

Server Hosting: Technical

Making sure a server component is easily deployable by others, including making generic deployment methods (Debian, Docker, Nix, K8s, ...) and integrating it in some hosting systems, ranging from hobbyist to serious commercial systems.

Docker ntfy — exists
K8s ntfy helm-chart — exists
Nextcloud: UnifiedPush Provider — exists
Matrix-Docker-Ansible-Deploy: ntfy-server — exists
Yunohost: ntfy-server — exists
SelfHostBlocks — not yet
CoopCloud — not yet
Fediversity (an upcoming hosting project) — not yet

Work out and write up (shareable) policies about who hosts, terms and conditions, privacy, rate limiting and other special measures, etc.?

Apps

Working with other apps to make sure they connect and work with UP out-of-the-box.

Category 1: default apps in /e/OS etc., like...

Mail: K9/Thunderbird-andriod #5165 and UnifiedPush for IMAP (NGI proposal 2024-10-535)
Nextcloud -uppush #17 -notifications #1225 -android #8684
Accounts/Calendar/Contacts (DAVx5 #36 + DAV-push)

Category 2: other popular apps like...

HomeAssistant #446344
Fluffychat — exists
Element — exists
Signal forks
Telegram-FOSS #577
Conversations.im — exists
Pixelfed #86

Standardising UP client-server protocol?

Should we consider standardising the UP client-server protocol? At present, by design, one must choose a UP distributor and UP server together as a pair. If we standardised the protocol between them, so any distributor would work with any server, this would certainly have some benefits, but also down-sides, and is not necessarily the right thing to do. UP was designed this way on purpose and achieves its goals without needing to standardise there. No ordinary person needs to be able to change their UP implementation. Only techies and service providers might like to do that.

Therefore this is an exploration rather than a development. I discuss this further in a separate article.

#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree

UnifiedPush: Standardise UP Client-Server Protocol?

Tue, 26 Nov 2024 20:00:00 +0000

This is a technical article. For a more general introduction to UnifiedPush you might read the first half of Going Google-Free with UnifiedPush in /e/OS or my other articles about UnifiedPush .

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.

UnifiedPush High Level Architecture

Look at the diagrams on the unifiedpush.org home page. There are four connections involved, shown arranged in a square. UP standardises the protocol for one of the connections, the bottom one (UP distributor <–> app). It also standardises something about how the whole system works.

The protocol on the top connection (App server –> UP server) has recently been upgraded to be compatible with WebPush.

The other two (App <–> app-server and UP <–> UP-server) are two other, separate, independent protocols. The protocol the app developer uses for app <–> app-server is not relevant to UnifiedPush. At present, UnifiedPush standards also do not specify a protocol to be used for the connection between the UP server and the UP distributor (shown on the left).

The ntfy distributor requires a ntfy server, whereas the nextpush distributor requires a nextpush server, and so on. They use different protocols for that link in the chain.

Multiple Protocols or Standardised Protocol

It would be possible to make a UP server that supports (for example) both the NextPush and ntfy protocol(s). In fact ntfy supports two different protocols (the “json” one and the “websocket” one) and you choose one in the settings. The ntfy server supports both of those.

The point is, UP achieves its goals without needing to standardise there. In some respects it's beneficial that the user and/or service provider can choose those components and protocol that best suit their needs, while the end-user apps and app servers all still remain completely compatible (standardised) no matter what UP components are used.

Additionally standardising the UP <–> UP-server protocol could make different UP servers and distributors interoperable. It could potentially help with users bringing their own choice of device (assuming it has a UP distributor built in) from one service provider to another, for example.

But that's more of a deployment-level standard: something that service providers might want to standardise. Android-compatible mobile OS's (for example) might get together and declare “we” (as a loose group) like to standardise on (let's say) ntfy-websocket protocol here, because (suppose) it works best with android's OS network layer and sleep optimisations. (Just examples; I have not researched what protocol actually works best in each scenario.) Then, Linux-based mobile OS's might choose a different protocol that works better with Linux's networking and sleep optimisations. Then, if a certain libre mobile service provider wanted to support both android-compatible and linux-based devices, they might choose to support two protocols. Or would standardising on one protocol be more helpful in such a scenario? It's not clear.

No ordinary person needs to be able to change their UP implementation. Only techies and service providers might like to do that.

So, at this stage this is perhaps the least important of all the areas to work on.

First explained in #unifiedpush:matrix.org.

#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree

Going Google-Free with UnifiedPush in /e/OS

Tue, 19 Nov 2024 12:00:00 +0000

Congratulations UnifiedPush! Congratulations Murena!

Murena's /e/OS 2.5 ships with UnifiedPush support included as announced by a small note in the 2.5-t release notes .

This exciting development brings Google-free push messaging to the regular users of an important player in the freedom mobile OS space.

So What?

Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently.

To achieve this, the phone operating system keeps a single network connection open to a push messaging server. The apps don't need to keep running in the background: they can go to sleep. When a push message arrives, the OS wakes up the relevant app and hands it the message.

All our apps share this push service — even the “private” ones — if they want push messaging.

That's great, except... Who Cares Who Delivers Our Notifications?

Until now, most people's phones run Google or Apple software. The Big Techs operate and control those phones. Along with everything else, they provide the push messaging service. And so they, Big Tech, control it.

The UnifiedPush public open standard changes this. With UnifiedPush, we are no longer merely “users” of our devices but are in charge of them. With UnifiedPush, we can choose which service provider will deliver our push messaging. Thereby we are in control of who has the ability to monitor or block our push messaging.

UnifiedPush has been available to those interested, for a while now, but until now it has required installing extra software.

Putting the support for push messaging into the operating system means ~~users~~ people who choose not to be operated by Big Tech will now be able to simply install the apps they care about and immediately have the alternative system working for them.

Technical

I'm going to delve into the technical side of this initial release, because it's a big interest area of mine. If you are a regular user, I suggest at this stage you might concentrate on switching to /e/OS or another freedom mobile OS and expect this functionality will be maturing quickly from now on and soon be seamless. If you're an early adopter or interested in its development, read on.

I am trying it out. I already run /e/OS on my main phone and upgrading to version 2.5 was simple with the built-in upgrader.

The OS embeds a custom fork of ntfy, calling itself “foundation.e.ntfy 1.17.0”. So, congratulations also to ntfy! At this stage the developer of ntfy, Philip Heckel, told me in #ntfy room he was “not yet involved” in this development and this is the “First I'm hearing about it.”

ntfy is a notification system that can also provide UnifiedPush service. It is so good at this job that it has for some time been the UnifiedPush implementation recommended for most people. One can install the ntfy app and it provides UnifiedPush service to our other apps.

When we install the ntfy app ourself, we may either let it use the creator's default server (at ntfy.sh) or configure it to use our choice of ntfy server, if we know of one or if we run our own. As with anything, using someone else's server comes with conditions and restrictions, especially if we don't pay for the service, so we need to think about that.

Let's see what /e/OS does.

If not Google's then Whose Server?

In this push service built in to /e/OS, there is no configuration UI. There is a tiny settings UI where we have to “enable” the service — see below. Technically, the full ntfy UI is also available, but not accessible through the normal system UI — neither the app launcher nor the settings. But as curious techies we can hack in to it if we like. See below.

What we can do is install and use the UP-example app. Click the “REGISTER” button, and we discover it's preconfigured to connect to... . o O (their own ntfy server?) No! It connects to ntfy.sh, the server run by the author of ntfy. Hmm.

I should say that I found this while not signed in to Murena's “e cloud” services. It's possible and would make some sense if it would point to a different server if signed in. I will be interested to find out.

The first thing to comment on, then, is Murena will surely need to run their own push server, for privacy and scaling and economic reasons, or else make an agreement with ntfy. In the short term, to get things started, it may be acceptable for everyone to be subject to the free (gratis) ntfy service's rate limits and other conditions. That's something that can be changed later, seamlessly, because UnifiedPush doesn't require app (server) developers to know or care which service provider they will eventually be connecting to.

Secondly, for privacy and self-determination reasons, there should be a way to use our own choice of server, but not necessarily as a dedicated configuration option. A better way might be to tie it to the main Nextcloud account through a single-sign-on, so that when we set up the phone we have only to make that one choice of service provider and expect it to cover all services. That would give people the advantage of simplicity which is how the Big Techs play that game, but now with open standard technologies enabling us to have a choice among service providers.

When an app registers for UnifiedPush service, if more than one distributor is installed, it asks which to use. A normal user would have only one, and would not see this. Here as an experimentor and developer I already had both ntfy and NextPush installed:

It's not ideal that it identifies as “ntfy”, exactly the same as the official ntfy app. I expect this will soon be changed to /e/OS branding.

The tiny settings UI is found a the bottom of the system settings menu.

It's disabled by default. In this state, the UnifiedPush service is still advertised to apps, and they can register, but push messages are not delivered. (I suspect this isn't how we want the disabled state to be. Probably it should not advertise as available.)

That's all the configuration we get in this version of /e/OS.

(Aside: I couldn't find this in settings, to begin with. Searching in settings for “ntfy” or “push” or “unifiedpush” doesn't return any results, for me.)

Let's Hack In

As a developer we can access the ntfy UI through the system terminal, for example through an ADB shell (running this command on a USB-connected computer with “adb” tool installed, with ADB USB debugging enabled in the phone's developer settings):

adb shell am start -n foundation.e.ntfy/io.heckel.ntfy.ui.MainActivity

Just the same as in the user-installed ntfy app. (I can compare them side by side because I also have it installed, because I was already using it before this upgrade.)

We first notice this screen prominently shows some warnings about battery optimisation and choice of connection protocol. Are these warnings relevant to this version?, I wonder. (At first it showed only the first, and later both.)

And it lets us open its settings. In the ntfy settings we can choose our own server, and I can confirm this takes effect and works.

This screen also shows the currently subscribed topics — here, the “example” one — and after configuring it to use my own server, the displayed URL confirms that. (Generally one “topic” corresponds to one app.)

Ntfy Not NextPush?

I'm a little surprised Murena chose ntfy, seeing as their system is closely coupled to Nextcloud: there is also Nextpush (source on Codeberg, yay!), a Nextcloud-hosted UnifiedPush server module and its client app, that could be used instead. Perhaps they found ntfy is more stable or refined than Nextpush.

UnifiedPush developer S1m says the “Next version of NextPush will be a lot more stable, and I've rewritten the UI.”

The Future

While UnifiedPush is pretty good standard already, it is still maturing. Some important, recent improvements are making their way into the standard and into implementations like ntfy right now. These include full compatibility with the WebPush standard, and a better way to wake an app without it needing permission for unrestricted battery usage.

An adjacent recent development is DAV Push, an open standard for pushing instant updates to our shared files, calendars and contacts through CalDAV, CardDAV and WebDAV, which can also work through UnifiedPush.

To ensure people can exercise their right NOT to depend on Google, we have wider work to do. Integrating a UnifiedPush distributor is one useful step towards it. Beyond this, we need to be working with the developers of popular apps to get them supported, sharing this development across the freedom mobile OS ecosystem, deploying servers, ensuring reliability, and more. I write about this in a follow-up post: UnifiedPush — Wider Developments .

Conclusion

The details of this initial implementation seem to me to indicate an early preview release, with significant changes still needed. But that's OK: these technical implementation details can be changed.

Leaving that aside, the social side of this is amazing: it's making UP available to main-stream users. That's a big deal for the libre mobile ecosystem. Hurray!

Add UnifiedPush to /e/OS to make it possible for developers to avoid FCM and better support F-Droid applications — an /e/ community forum thread requesting UP support.
Source code of /e/ fork of ntfy: https://gitlab.e.foundation/e/os/ntfy-android
“Integrate ntfy in /e/OS” —merge request, including a simple settings UI (just enable/disable).
Romain Hunault of Murena is presenting it at Capitole du Libre 2024 this afternoon.

#unifiedPush #degoogled #awesomeFOSS #eOS #Murena #ntfy #mobiFree

Forĝejo Team/Project Namespace

Thu, 14 Nov 2024 15:11:18 +0000

POSSE: I added this as a comment on the Forgejo discussion “[FEAT] Proposal to extend Forgejo URL structure...” on 2024-11-14.

Something perhaps not fully explored in this conversation is: Who are we building this for? I note that the original request/suggestion was specifically for Codeberg.

Forgejo (.org main page) says it is a “self-hosted lightweight” forge, but also “focuses on ... scaling ...” That means, apparently, Forgejo is both for personal tiny use cases, and for big multi-tenant operations like Codeberg.

Adequately supporting both tiny and huge cases requires flexibility. Flexibility of the structure.

This request, initially framed as extending the namespace to add one new level, and subsequent discussions to perhaps add multiple levels, is great for big, multi-tenancy deployments.

What about the small end of the scale? In a small scale deployment I would like the ability to drop the “organization” level (because it all belongs to just me or my single org), and just have projects directly at the top level.

Or even — and let's give this thought a chance before immediately rejecting it — the possibility to run a single-project (repo) instance. (Need more projects? Spin up more lightweight instances.)

I am not raising this to be argumentative. I have given a lot of thought to the issues of self-sovereign identity and federated services, and the context of hosting them. The “instance of one” principle which applies so well to Fediverse and Matrix servers also applies here — it is the only way for a tenant to own their own identity (as far as “ownership” goes for DNS), when the software platform is constrained to serving only one domain per deployment. Making services support the “instance of one” paradigm, and be light-weight, is a key enabler of self-sovereign identity. (Making bigger deployments support Bring Your Own Domain multi-tenancy is an alternative.)

In my use cases, I run a personal instance and one for my tiny (personal) company. In both cases I don't need to configure “organisations”, and I don't want that part of the UI because it is unnecessary clutter and cognitive load. It's not huge but just seeing “organization” in the UI, or seeing the panel for configuring an org's contact details, puts me off.

However I do find nested project name-spaces to be helpful. Currently I use (abuse) the “organization” level for achieving a single level of nesting. I fill in the “org” name and sometimes the description field; and I leave all the contact details blank. This works ok but it does not give the professional look that I would like to give: I would like my work to be presented with the UI indicating name-spaces but NOT pretending they are “organisations” in the sense of company businesses.

TL;DR: If we make any change, let's make sure we make life better for light-weight single-tenant use cases as well as big ones.

julian

Wanted: Digital Dreams

Bye Bye Facebook

Why Disconnect?

Where To?

See you in the Free(dom) World

Music By Computers

Caught in a Self-Sovereignty Self-Hosting Knot

Enter your Bossname

Open Source Considered Harmful -- Choose Your Browser Wisely

Google Chrome vs. Mozilla Firefox

UnifiedPush -- Wider Developments

How We Get There

OS Integration of the UP Distributor

Server Software

Server Hosting: Technical

Server Hosting: Social/Business Aspects

Apps

Sharing with other mobile OS projects

Standardising UP client-server protocol?

UnifiedPush: Standardise UP Client-Server Protocol?

UnifiedPush High Level Architecture

Multiple Protocols or Standardised Protocol

Going Google-Free with UnifiedPush in /e/OS

So What?

Technical

If not Google's then Whose Server?

Let's Hack In

Ntfy Not NextPush?

The Future

Conclusion

Forĝejo Team/Project Namespace