lorenzleutgeb

Joined 8 years ago

Karma
121
Submissions
33
Member since
Jun 11
meet.hn/city/49.2343620,6.9963790/Saarbrücken

Socials: - bsky.app/profile/lorenz.leutgeb.xyz - https://lorenz.leutgeb.xyz

Interests: Open Source, Programming

---

[ my public key: https://keybase.io/lorenzleutgeb; my proof: https://keybase.io/lorenzleutgeb/sigs/IOrcOrzk60NWHqMSLNt_jjlRUvVpaXvMFotW3azU3sY ]

View on Hacker News

Recent submissions

Comment · 5 months ago
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...

Comment · 6 months ago
Comment · 9 months ago
Comment · 9 months ago
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.

Comment · 9 months ago
Comment · 9 months ago
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.

Comment · 9 months ago
> 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?

Comment · 9 months ago
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...

Comment · 9 months ago
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).
Comment · 9 months ago
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.
Comment · 9 months ago
Comment · 9 months ago
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.

Comment · 9 months ago
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.

Comment · 9 months ago
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.
Comment · 9 months ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton