Because there are so many different Linux distributions, we plan to adopt Flatpak (https://flatpak.org) and publish Keychat on (https://flathub.org) so that Linux users will be able to install Keychat easily from Flathub.

We also intend to add the Mini App Browser to the Linux version of Keychat, and in parallel we’re exploring future support for ARM-based desktops and laptops.

In the past, we largely overlooked this Lightning Pub–style design direction.https://lightning.pub

Most conversations about “second-best” Lightning wallet models tend to focus on large global hubs—custodial Lightning wallets or new protocols like Ark and Spark. It’s worth stepping back and mapping out the design space more clearly.

When users run their own Lightning nodes and channels, they are both part of a decentralized network and in full custody of their own funds. This is the ideal wallet model.

In reality, not everyone can do this. That opens up a design space for “second-best” solutions, mainly along two axes: the degree of centralization and the degree of third-party custody.

It’s important to note that centralization and third-party custody do not always perfectly overlap. In other words, a centralized architecture does not necessarily mean that 100% of funds are fully custodial at all times.

1. For wallets like Coinos and Wallet of Satoshi, they are both global hubs and fully custodial: user funds are entirely under the control of the service operator.

2. Ark and Spark also move in the direction of global hubs. They still follow a server–client architecture, but their goal is to allow users to exit unilaterally. If the service fails, users should still be able to move their funds back on-chain into UTXOs they control, getting as close as possible to self-custody.

However, their default transfers do not achieve Lightning’s instant finality. There is a time window in which the service provider and the previous owner of the funds (and in many cases, the operator is also the previous owner) could theoretically collude to double-spend. During those windows, users are not at 100% self-custody over their funds.

3. Lightning Pub takes a different path: its goal is to let more technically capable users provide custodial wallets to their friends and become local micro-hubs.

Its focus is on lowering the technical barrier for “sharing your own Lightning node and channels” with people around you. That’s why Lightning Pub:

1. uses Nostr IDs as the basis for its built-in multi-user account system, and

2. uses encrypted messages relayed over Nostr relays (DM/RPC) to connect front-end wallets with the back-end node.

So Lightning Pub is the Nostr-native Lightning node.

In this sense, Lightning Pub effectively gives more people the opportunity to run their own small Wallet of Satoshi / Coinos–style custodial Lightning wallet, but scoped to a local circle of friends. Because these relationships are often built on existing social trust, the risks normally associated with third-party custody are partially mitigated.

Once large, obvious centralized service hubs emerge, whether they are traditional custodial Lightning wallets or large Ark/Spark operators, they become much easier targets for regulators and governments to shut down.

nostr:nevent1qvzqqqqqqypzpwleyw4fy3sxt7yvgrran0mpenxqlululur94r9jlax0hd3q3rc7qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpq0xfd8a6y4rq6pvd4gmnxrafln2h3shs74ustmzdawk7jax9y8wcs8a7hj2

nostr:nevent1qqs82u5gxj95wdnv822my8a4l7duhjvltchdvpyafg3q2efkdv8f5cgpz9mhxue69uhkummnw3ezuamfdejj7q3qf6ugxyxkknket3kkdgu4k0fu74vmshawermkj8d06sz6jts9t4ksxpqqqqqqz3ez3rt