lorenzleutgeb

How does this not mention alternatives? Here: UnifiedPush.org

And the author is also wrong that all notifications on my phone go via Google. Signal and Mastodon notifications are set up via Sunup.

They seem to have given up. Don't do that please...

For the reason of hbsd moving, see https://bsd.network/@HardenedBSD/116437657126172879

As Radicle is written in Rust, I was hoping for a way to use Kingfisher as a library, but did not find one. So I filed https://github.com/mongodb/kingfisher/issues/189

Of course, it'd always be possible to invoke some binary. But I am still curious about a library.

For the source code in the repository, conflicts must be merged by users (or their tools, like `mergiraf`), just like with any other Git repo containing source code.

What might confuse you is the mention that a collaborative object may opt in to ask the user to resolve a conflict. Well, in this case, strictly speaking, it's not a CRDT anymore of course. But none of the collaborative objects commonly used in Radicle use this escape hatch.

It is clear that Git itself does not give you CRDTs, but Radicle implemented CRDTs on top of Git, which is entirely possible. This is also what's explained in the Protocol Guide. I don't understand what's the misunderstanding here, sorry.

Where are you quoting from?

Radicle implements so called "collaborative objects" (think: issues, patches, anything that multiple users collaborate on; except the source code itself) as CRDTs: https://radicle.xyz/guides/protocol#collaborative-objects

In the Radicle ecosystem, quite a few people like the idea to "seed" repos that they want to support. It means that you download the repo, and also announce to other nodes that you have it available to share. Thus, you are not only incrementing some counter in a central database, but you are actually contributing to the replication of the project on the network.

The number of seeds then is a similar indicator as the number of stars.

Of course, you can also just keep a list of repository IDs.

> I keep thinking about people putting secrets up in github.

You gave me an idea. For Radicle, we implemented a `git-remote-helper` (Git recognizes `rad://`-URIs and then wakes up the helper to handle the rest). This helper could well look at the blobs being pushed and detect secrets. Then error out and request a retry with `--force` if the user is sure.

To implement something like this, we'd not want to reinvent the wheel, so we'd want to consume some description of patterns that we should look for. And obviously we're not going to ask GitHub or some web server.

So, is there such library? In a format that is simple-ish to implement filtering for but also catches a good amount of secrets?

Check https://app.radicle.xyz/nodes/seed.rhizoma.dev/rad%3Az3yQUb9...

What's tricky here is to do it in a way that GitHub users properly map to Radicle identities. We will get there...

A lot has changed. But also you must've checked it quite some time ago. It's not on the blockchain anymore since the "heartwood" iteration, which was announced 2023-04-18. Please take some time to re-inform yourself, even just in this HN thread (search for "RAD ", the whitespace is significant).

It's a valid question, and in fact there's quite some interest in adding write features to the web app. The current version of Radicle was designed with one user per node in mind, to get things off the ground. The process of relaxing this is currently ongoing. First, to multiple users per node, which would make use-cases like the one you are sketching viable. What we'd like to avoid is to hand the key to the server, in such case, and instead generate an Ed25519 key in the browser, and sign there, with some web-compatible transport (HTTP? WebSocket?) in between. And that's just a bit more intricate than it sounds.

> If the internet is down and you want to onboard someone with say, a usb thumbdrive.

All the data being synced is in a Git repo, which is in a directory on your filesystem we call "Radicle Storage". You can use `git bundle` or a plain `cp` to copy that directory over. You can also use plain Git to push. Note that for these use-cases there is no polished UX. You need to know what you are doing. The bigger issue will be to install Radicle.

> With the mirroring: does radicle have any kind of event hooks?

Yes. You can connect to `radicle-node` via a socket and subscribe to events. This is how Radicle CI, and in particular the Radicle CI Broker was implemented. You can implement your own event broker, it's just JSON over a socket.

https://radicle-ci.liw.fi/radicle-ci-broker/ci-broker.html

There's `rad sync status` which will show you (for a particular repository) which other nodes have echoed back to you that they have received and verified the most recent state of your namespace of that repository. So, if you expect some other node to have received your changes, you can use this command to verify that.

When the user explicitly asks to sync, then by default the process will be considered to have completed successfully as soon as three other nodes have echoed that they have received your changes. This threshold is configurable. Further, one can define a list of nodes that they care particularly much about, in which case the process will only be considered to have completed successfully if all these nodes also signaled that they have received your changes.

For anything deeper than that, you'd have to resort to logs. And if you connect your node to the other one your are interested, you can get a pretty good picture of what's going on.

If one node "falls off" the network, then the above mechanisms will communicate that to you, or fail after a timeout.

With Git repositories, humans establish order explicitly. They push commits which are a DAG. The collaboration around that (mostly discussions on issues, patches) is also stored in and synced by Git, but here, humans do not have to establish order explicitly. Rather, these things, in Radicle lingo called "Collaborative Objects" are CRDTs, so they will merge automatically. Nodes also opportunistically tag operations on these CRDTs with the latest operation they know, to help a bit by establishing an order where possible.

Right. Radicle nodes out of the standard distribution would be kind enough to delete. On the technological level you cannot do more (also not really less, funnily enough). But it would be possible to patch the code and remove deletion.

Often times I just take the "information theory perspective": You fundamentally cannot make something "more private". Once it's out, it's out. You cannot "untell" a secret. That's just not how it works.

But then other solutions also have this problem. Once I have `git fetch`ed from GitHub, or received that e-mail containing a patch on a mailing list, I have a copy on my filesystem. It's going to be pretty darn hard to remove it from there if I don't comply. Maybe you'd have to enforce some law.

In that context, it seems that people were led to believe that "removal from the server(farm)" is the same as "removal from the universe", but that's just not true.

Happy for any insight on how to approach this differently.

Tor only (SOCKS) or Tor and clearnet is easy. Yggdrasil only is also easy (just restrict access to your tun). Yggdrasil and clearnet requires you to ensure that outgoing traffic takes the correct interface, this also applies if you want to combine with Tor. I don't know about I2P.

Right. Radicle would be one way to connect all these Raspberry Pis in many pantries together, and have them replicate each others repos. It also enables others to send patches, without first having to create an account on that Raspberry Pi in your pantry. And in case your Raspberry Pi is offline, others will just as happily serve your project, with cryptographic assurance that it wasn't modified.

Don't get me wrong. Power to you and your Raspberry Pi! Radicle invites you to join a network of people that solve the same problem as you do, and pool resources.

Currently, with Radicle still under active development, we already reach convergence times that are negligible for async collaboration (like working on code or issues). Working on a well-seeded repo, my changes sync to ~10 nodes within a tenth of a second and with ~80 nodes within 3 seconds.

This is obviously not fast enough for sync collaboration, like writing on a virtual whiteboard together, but that's also not what Radicle is designed for. Also, if you share larger files (e.g. you attach a screenshot to your issue) the above times might not be a good estimation anymore, but that's the exception for now.

It's really strange to see that people assume that peer to peer networks somehow must be slow. In my experience, since everything runs locally, working with Radicle feels way more snappy than any web interface, which has lots of latency on every so-odd click.

As the network scales, it'll of course take some care to keep the speed up, but that's known and there are a few models to take inspiration from.

> is there a mirror adapter to push to a non-radicle node, such as Github or say, sourcehut?

You can just add a remote for another repository.

    git remote add github [email protected]:example/example.git

You can also create remotes with multiple push URLs, so that with one `git push`, you push to all of them at once.

Apart from that, it's possible to use e.g. systemd path units to run `git push` automatically whenever a repository gets updated by `radicle-node`.

This works reasonably well. What else would the adapter have to do?

> is there a mechanism to control syncs so it can be used on low-bandwidth, unreliable networks, or ad-hoc bluetooth networks?

No. The data itself usually is quite small, as the common use case is to send commits. It's not optimized for unreliable networks or Bluetooth in any special way yet. It would certainly be useful.

> is offline seeding possible or in the works?

That's contradictory in my mind. What do you mean? Offline in the sense of "not connected to the internet"? That works just fine. Currently, you still have to connect your node to the existing network by connecting to another known node (via IP address or a DNS name that resolves locally). There are plans to integrate DNS-SD, also via mDNS.

> language package managers often can reference a git or github. Would I be able to directly reference my local radicle node and have it manage (or perhaps even discover) the correct repos?

For now, no. It's however reasonably simple to deploy a component called `radicle-httpd`, which will expose your repos via Git over HTTP if you like. Looks like this: https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git

> (Or maybe this is a different problem and package repos themselves could be decentralized and sovereign)

Yes. Consider things like https://www.tweag.io/blog/2020-12-16-trustix-announcement/

Radicle is a free software project, not a company or commercial product. Many other open source projects are also not monetizable in the narrow sense, and still manage to attract enough contributors and funding to flourish. Sometimes these projects even get adopted so widespread that multiple companies build consortia/foundations to fund the development, even if there is no direct revenue stream from that.

As long as someone is willing to fund the development of Radicle, the developers just will have a stronger incentive to work on it. Without any more funding, of course it will join the (very large) club of less well funded free software projects.

If enough people join and contribute now, and then some companies make the switch, it might well be feasible to pay a small team to continue working on it, financed by donations.

Just don't think about it as a commercial product, only because someone decided to use their money towards its development. If you don't like that it's not a company, then that's okay. I am just trying to give another perspective.

For CI, please refer to https://radicle-ci.liw.fi/ and https://radicle.xyz/2025/07/23/using-radicle-ci-for-developm...

First, to make this clear: The Radicle network is not dependent on any blockchain technology, you can use it without holding any cryptocurrency/token. You do not need a wallet. You just need to generate an Ed25519 keypair for yourself.

Radworks and RAD are still a thing, and the last vote (https://community.radworks.org/t/3698 and https://community.radworks.org/t/3703) was to fund Radworks App (https://radworks.org/app), Drips (https://www.drips.network/), Radicle Garden (https://radicle.garden/).

Radicle development is funded by the Better Internet Foundation (https://betterinternet.foundation/), previously called "Radicle Foundation".

RAD "tokenomics" are discussed here: https://community.radworks.org/t/3645/

Yes. Radicle also makes it easy to run behind Tor, see https://radicle.xyz/guides/user#4-embracing-the-onion and there are people that use it via Yggdrasil, see https://yggdrasil-network.github.io/services.html#radicle-no...

Radicle is peer to peer. There are no "instances" or "servers" you interact with. The process that runs on your machine to synchronize changes across the network is the same as you would run on a server somewhere else. This is the core difference in network topology.

What Forgejo are working on is to have their servers/instances communicate with each other via ActivityPub (IIRC). Think about it more like GitHub : Forgejo :: Twitter : Mastodon and possibly Filesharing : BitTorrent :: Software Development : Radicle.

With Forgejo, every instance has its own database of user accounts, and controls who may log in or not (and so on). This is not the case with Radicle. Since there is no such authority, user accounts are self-certifying.

For repositories, since there is no "standard location" like "the server", Radicle has developed a way to abstract from the user namespaces of the maintainers of a repo, to a canonical namespace. This is how references are lifted from individuals to a project. Not by having a copy on some particular server with access control. Of course, Radicle also has access control, but it is tied to the self-certifying identities, not to some server.

Tangled is built on top of the AT Protocol, and "mediates" between what they call "knots". Git servers. Their strength is to use AT Protocol to make communication across multiple Git servers work smoothly.

Radicle is completely peer to peer. There are no such things as servers and clients, only nodes. However, there are quite a few nodes that then act as HTTP servers to offer convenient access via the browser.

No. Please refer to https://radicle.xyz/guides/user and read this to understand the concept of "policies". This should answer your question, but otherwise of course I am happy to explain further.

What is the data you actually store when caching a successful test run? Do you store the hash of the expression which is the test, and a value with a semantics of "passed". Or do you have a way to hash all values (not expressions/AST!) that Unison can produce?

I am asking because if you also have a way to cache all values, this might allow to carry some of Unison's nice properties a little further. Say I implement a compiler in Unison, I end up with an expression that has a free variable, which carries the source code of the program I am compiling.

Now, I could take the hash of the expression, the hash of the term that represents the source code, i.e., what the variable in my compiler binds to, and the hash of the output. Would be very neat for reproducibility, similar to content-addressed derivations in Nix, and extensible to distributed reproducibility like Trustix.

I guess you'll be inclined to say that this is out of scope for your caching, because your caching would only cache results of expressions where all variables are bound (at the top level, evaluating down). And you would be right. But the point is to bridge to the outside of Unison, at runtime, and make this just easy to do with Unison.

Feel free to just point me at material to read, I am completely new to this language and it might be obvious to you...

What this is trying to say: - "peers": participants in the network are peers, i.e. both ends of a connection run the same code, in contrast to a client-and-server architecture, where both sides often run pretty different code. To exemplify: The code GitHub's servers run is very different from the code that your IDE with Git integration runs. - "replicated across peers": the Git objects in the repository, and "social artifacts" like discussions in issues and revisions in patches, is copied to other peers. This copy is kept up to date by doing Git fetches for you in the background. - "in a decentralized manner": Every peer/node in the network gets to locally decide which repositories they intend to replicate, i.e. you can talk to your friends and replicate their cool projects. And when you first initialize a repository, you can decide to make it public (which allows everyone to replicate it), or private (which allows a select list of nodes identified by their public key to replicate). There's no centralized authority which may tell you which repositories to replicate or not.

I do realize that we're trying to pack quite a bit of information in this sentence/tagline. I think it's reasonably well phrased, but for the uninitiated might require some "unpacking" on their end.

If we "lost you" on that tagline, and my explanation or that of hungariantoast (which is correct as well) helped you understand, I would appreciate if you could criticize more constructively and suggest a better way to introduce these features in a similarly dense tagline, or say what else you would think is a meaningful but short explanation of the project. If you don't care to do that, that's okay, but Radicle won't be able to improve just based on "you lost me there".

In case you actually understood the sentence just fine and we "lost you" for some other reason, I would appreciate if you could elaborate on the reason.

Please check out radicle.dev, helping hands always welcome!

Check the Wayback Machine. It has archived some of the previous iterations: https://web.archive.org/web/20250000000000*/radicle.xyz

Comparing to index funds is neat. What Flattr.com offered was to set a monthly budget and then not allocate according to an index but according to your preferences (value per flatter = monthly budget divided by number of flatters).

Flattr is no more. But I could see that work out for open source projects: Allocate a fixed monetary amount per unit of time you want to donate. Record "intent to donate" during that period. This could be done via a browser extension or a CLI. At the end of one period, distribute.