[HN Gopher] Towards a secure peer-to-peer app platform for Clan
___________________________________________________________________
Towards a secure peer-to-peer app platform for Clan
Author : throawayonthe
Score : 66 points
Date : 2025-12-23 17:34 UTC (5 hours ago)
(HTM) web link (clan.lol)
(TXT) w3m dump (clan.lol)
| jackpepsi wrote:
| I think they explain a compelling problem about typical
| commerical software vs FOSS, then they dive into their GPU
| accelerated VM solution. I don't see how it helps solve the
| original problem.
|
| Is is that FOSS needs a standard sandbox and they think some kind
| of peer to peer app store that disturbes images for VMs is the
| way to do it?
| Mic92 wrote:
| We work on GPU accelerated VMs, so that in future we can also
| bring NixOS + VPNs to desktops/end users to machines that don't
| run NixOS. We will use it as an application runtime where can
| control the whole stack. Just now we are mostly focused on
| managing distributed NixOS machines. The VPN helps to provide
| services on any kind computer, even if not running in a
| datacenter. You can read the description here for context:
| https://docs.clan.lol/
| guerrilla wrote:
| Maybe I'm in the same boat as people who didn't get docker
| before it was popular, but this seems really convoluted to
| me... is there really a market for this? Why do other
| existing things not solve this problem?
| dist-epoch wrote:
| There is huge demand right now to create sandboxes for
| agents. VMs are one way, and Clan one solution for VM
| management.
|
| Maybe they are not the right solution, but they are working
| on the right problem.
|
| Of course, they don't say the focus on agents, but if the
| solution works with them, it doesn't matter that it was
| built for gamers.
| lifty wrote:
| Is clan some kind of p2p server config management framework based
| on Nix?
| Mic92 wrote:
| I think this fits the description well.
| trinsic2 wrote:
| I'm not understanding the need for this? I cant believe i'm
| parroting corporate lobbyists, but this seems like a solution in
| search of a problem.
|
| It sounds more like a way to take freedom away from people.
| Commercial systems are designed in such a way that offering that
| convenience is at the expense of control and ownership. Just
| because people trade freedoms for this level of ease, doesn't
| make it right.
| IlikeKitties wrote:
| It's a bit of a two edged sword but it's something we
| definitely need. Look at project like Qubes and Secureblue that
| try to implement this. It solves several issues:
|
| Packaging Apps on Linux has been and always will be, a
| nightmare. Just giving up and sending whole VMs is basically a
| variant of what docker does.
|
| Permission Management is also quite necessary and Linux
| Desktop/DBUS is horrible in that regard. There's recently been
| a post about this[0]. Especially part 5 is just... GNOME
| Developers being GNOME Developers...
|
| A lot of Apps also open untrusted files and even run untrusted
| code. Browsers, PDFs, or Excel Macros? God only knows what kind
| of exploits and hidden software landmines there are.
|
| And last but not least there's also just badly coded apps that
| can get pwned from remote sources. Think some game running
| horrible c++ code connecting peer to peer with random clients.
| All of them could easily buffer overflow some random function
| and take over all your files.
|
| [0] https://blog.vaxry.net/articles/2025-dbusSucks
| orbital-decay wrote:
| Taking the control from you is a corporate decision, not the
| inherent property of compartmentalization.
| lrvick wrote:
| Yet another reminder that Nix does not sign commits, does not
| sign reviews, allows any maintainer to merge their own code, does
| not compile all packages from source, and Hydra admins can
| absolutely tamper with builds at any time. It is a massive supply
| chain attack waiting to happen.
|
| The Nix team is aware of all of this and made these tradeoffs
| intentionally to maximize package support and reduce contributor
| friction. Nix, for all its good design choices, landed on a
| supply chain integrity threat model that unfortunately makes it
| suitable only as hobby OS that must not be used to protect
| anything of value.
|
| Guix at least signs commits, but individual maintainers are still
| trusted so it is not much better, so there really is no
| production safe nix based package tree I am aware of.
|
| Nothing should advertise itself as secure while being based on
| nix.
|
| Just because something is popular, does not make it safe.
| tkz1312 wrote:
| which packages are not built from source?
| lrvick wrote:
| Just a couple examples off the top of my head I have bumped
| into: Packages that cannot be full source bootstrapped like
| Haskell are allowed, so total trust is placed in a third
| party compiler binaries. Also in cases like qemu where binary
| blob firmware is in the repo, it is kept as is and not
| rebuilt from source. Determinism is also not mandated so
| there is no way to know if any of the non deterministic
| packages were faithfully built from source. There are no hard
| enforced rules in cases like these, only cultural guidelines
| that are followed optionally.
|
| Compare to e.g. stagex which I founded specifically because
| nix did not wish to adopt a strict threat model that trusts
| no single individual, build machine, or third party binary.
| cobertos wrote:
| Sublime Text for example[0], the source is closed, so what
| else is there to do
|
| [0]: https://github.com/NixOS/nixpkgs/blob/76701a179d3a98b076
| 53e2... (does a fetch URL against the pre built .tar.gz from
| https://download.sublimetext.com)
| gz5 wrote:
| for the private networking problem, openziti (apache 2.0) is now
| integrated with Nix:
|
| https://github.com/NixOS/nixpkgs/pull/453502
___________________________________________________________________
(page generated 2025-12-23 23:00 UTC)