AD: Feel free to take a stab at an alternative, we're an open source project and we accept and welcome discussions but patches more so! What would read better in your opinion?
You're asking someone else to describe what your project is doing?
The lack of good description isn't unique, I've bee skipping more and more of those lately, but asking others to tell the developers what they've developed is new in my book.
Sometimes when you’re close to something it’s very hard to describe it because you’ve been looking at it from all angles for so long that when someone else approaches it from a different direction it’s hard to see what blind spots they might have. It’s not crazy to ask people for input and it’s not crazy to say “we’re open to patches if you just want to do it yourself”.
For me personally I was (and still am a bit) unclear on what being “based on git” means. Can I just rebase with abandon? Is there a concept of force push? Can I safely use lazy-git, tig, commit-patch, and other git utilities? Or is it more integrated and i have to use the rad cli to avoid corrupting the git repo? What about the issues? If I write some software and publish it with radicle, is there a way for plain git client to clone the repo without installing radicle (and without keeping a plain git mirror somewhere)?
Each repository is governed by an identity document which is signed by a set of delegates, each delegate currently corresponds 1:1 to someones ssh-key. We are working to adjust this mechanism so you can have group identities, but its a hard problem and we're not the only ones working on it (note theres light at the end of this tunnel at this point).
Seeing as you studied philosophy I'd argue what then do you mean by a solution? Aren't all solutions transmutations of prior 'things'? In the complex domain we have a word for it, exaptation - the radicle repurposing of something in a new context.
That aside, how do you know which people to trust when you meet them? And how do you signal trust in those you've met? In Radicle holding stable cryptographic identities doesn't resolve the zero-to-some trust problem but it does resolve the some-to-more trust problem, I can continue trusting once I recognise and know an identity.
So to answer "how is that trust distributed to parties in the network" - by stable cryptographic identities.
To answer "how do I know which stable repository identities to trust" - by socialising, like you know how to trust people you meet in the world because you were introduced to them by someone else you trust.
I guess what I mean is that trust is a hard problem, and a lot of solutions to trust involve transmuting a presupposed trust problem into a different trust problem with a slightly different security model.
For example: with a centralized service, I assume that a given identity is integral so long as the service is secure. I don't need cryptographic identity for that centralized service, but that assumes I trust the service to be secure.
With a distributed service, I need some way to ensure the integrity of identities. One way to do that is to TOFU, i.e. take a claimant identity on face value on first observation and then trust it going forwards. This works well for schemes like SSH, but it doesn't work super well for distributed user networks (because users like to lose their keys, and there's a larger potential surface area for undetectable key substitution).
Another solution is a "web of trust" architecture, where you take an initial trusted core and transitively extend trust outwards. The problems with this are (1) that trust isn't actually transitive, and (2) it still presupposes a trusted core, which needs to be bootstrapped somehow.
A third solution is a traditional PKI, where you have one or more pre-established identity "authorities" that sign for end user identities. This is the solution that HTTPS picks, and is arguably the most empirically proven of the decentralized identity schemes. But it's only as decentralized as the authorities themselves are, and there's a meaningful argument to be had about that (particularly in schemes that are smaller than the Web PKI).
It sounds like Radicle is going with a mixture of (1) and (2), which is interesting and worth proving out. But my experience is that "someone's SSH key" is much less of a stable identity than we'd all like it to be, and schemes that involve delegating trust via unstable identities eventually run into architectural limitations that end users solve by just subverting the scheme itself (i.e. falling back to TOFU).
> That aside, how do you know which people to trust when you meet them? And how do you signal trust in those you've met? In Radicle holding stable cryptographic identities doesn't resolve the zero-to-some trust problem but it does resolve the some-to-more trust problem, I can continue trusting once I recognise and know an identity.
This is a good example both of how (1) social trust isn't easy to encode in cryptographic claims, and (2) how the transitivity of trust breaks down.
In the real world, I trust my barber to cut my hair and my dentist to look at my teeth. But I only trust them for their apposite roles, and my trust in my barber doesn't necessarily mean anything to my friend who doesn't like my haircut.
Your comments of trust reminded me of an analysis of the PGP strongly-connected component of the "web of trust," back when keyservers were a bigger thing, and essentially found that, in practice, "web of trust" turned out to have a lot of key nodes that look very much like CAs in Web PKI.
That is, for as much as a lot of cryptoenthusiasts want to talk about decentralizing trust and empowering users to have fine-grained trust decisions, in practice, most users really just want to offload all of the burden of ensuring someone is trustworthy on somebody else.
Yeah, very much in the same vein. Someone should probably produce a pithy phrase for “if you think you have a web of trust, you probably have an informal, underspecified central authority.”
I agree trust is a hard problem when your coming from a problem<>solution framing. Trust is pretty abundant in our day-to-day lives if not a slightly backgrounded, for example; I trust my keyboard to type until the batteries run out or wear & tear gets the better of it, I trust my partner to hold care for me in mind when making decisions for me, I trust my dog to come back to me when I call for him... etc. In all those cases I've engaged on a epistemic and phenomenological journey mutually validating (at least) my experiences, my expectations and my actions. Because I remember my dog coming back to me in my previous experiences I trust and as such expect him to do so in the future. Because my keyboard continues to reflect my intent in writing this, I trust it is operating correctly. Because my partner has shown care for me a prior, I trust she will continue to do so.
I agree with your representations of centralised, TOFU and PKI.
> It sounds like Radicle is going with a mixture of (1) and (2), which is interesting and worth proving out. But my experience is that "someone's SSH key" is much less of a stable identity than we'd all like it to be, and schemes that involve delegating trust via unstable identities eventually run into architectural limitations that end users solve by just subverting the scheme itself (i.e. falling back to TOFU).
You're right 'someones ssh key' is unstable (not to detract from my my point but in the real world trust can be fickle and unstable too), however we can increase our certainty and are intending to. I'm interested in bring HSM's into Radicle, that swaps something you have on your computer to something you have on a physical device, but there are also further advancements like have been seen in the world of Keri where you can delegate identity to a log (KEL) which act as Autonomic Identifiers, these are self-sovereign, self-certifying sources of truth, we can have a set of keys and rules that govern the usage of them such that only 1 is valid at a time and if it is lost or compromised we can rotate safely and continue doing so.
> This is a good example both of how (1) social trust isn't easy to encode in cryptographic claims, and (2) how the transitivity of trust breaks down.
Agreed on 1.! I'd rather keep people good at what people do (continuously making and sharing trust judgements by engaging in the world) but enabling them to reflect that easily in their digital life. As for 2. I think it goes both ways depending on the context, it can breakdown but it can also compound amongst a plethora of other variations.
> In the real world, I trust my barber to cut my hair and my dentist to look at my teeth. But I only trust them for their apposite roles, and my trust in my barber doesn't necessarily mean anything to my friend who doesn't like my haircut.
I disagree, when talking conceptually of the role of barbers and trusting them at cutting my hair I agree, however when I go out into the real world and interact with my barber I trust them with more than just that! In fact I'd imagine many barbers would be offended at the idea they are ONLY trusted to cut hair in the barber shop. Try have that conversation with your barber next time you are there - if they aren't hurt by the idea of being reduced to a single role you might of found yourself a robot!
As for your trust in your barber meaning nothing to your friend who doesn't like your hair cut, I'd imagine your trust would of changed given the bad hair cut, but we could split this many ways, your friend might not like your hair cut but you like it - thats not much to do with the barber, your friend might not like your hair cut and you don't like your hair cut, not really a conducive situation for a recommendation, you might not like your hair cut and your friend might love it, now how loyal is your friend? Any attempt to enumerate out all of the variations is feeble, but hopefully the point comes through that theres a lot more going on than we can reduce.
AD: We're looking ad introducing 'forgetting' as a feature, there may be a mutually beneficial way of signalling to permissive seeds when content is no longer relevant or stale or actively been flagged for removal.
AD: We're actively working on that issue right now, making the defaults safer. We're also discussing internally how to enable revocation of content at the network level. It won't be perfect, but neither is GitHub or the likes.
> We're also discussing internally how to enable revocation of content at the network level.
Isn't that a solved issue? Or rather unsolvable. With ActivityPub there's just a deletion notification that's obfuscated so that you can't identify the item unless you already have a copy of it. What else can you do?
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.
I am just glad some thought is being put into it. Thanks for the efforts.
I keep thinking about people putting secrets up in github. You can not really get rid of something that is out there, like you said.
But people do make a request to github to remove it. And if no one has put in the effort to copy it and republish it, it is not as "out there" as if it were still on github.
Thinking on old BBS boards on the internet. Most people will use Internet Archive to search for old dead sites. If it is not on there, it is not as "out there" as if it were on the Internet Archive.
I am thinking it is not quite as black as white as it seems. There is some kind of entropy effect.
Thinking on pre-internet newspapers. If you posted something in a fan zine in the 70s, it might have faded from existence due to lost copies, or it might be in some collector's stockpile. It might even be scanned into the Internet Archive. Or not.
No great solutions come to mind. But there does seem to be some "small" value in being able to say, delete this as it was a mistake.
Maybe, also, more education, or a warning about "beware, be extra careful, this is going to be around for all to see for a long time, possibly forever".
> 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?
Not the original OP — I had been thinking about this for years, though my interest is in resiliency rather than a sovereignty (though they overlap):
- is there a mirror adapter to push to a non-radicle node, such as Github or say, sourcehut? (Mirroring nixpkgs, for example)
- is there a mechanism to control syncs so it can be used on low-bandwidth, unreliable networks, or ad-hoc bluetooth networks?
- is offline seeding possible or in the works?
- 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? (Or maybe this is a different problem and package repos themselves could be decentralized and sovereign)
On that last point, I mean that the whole build chain and supply chain can be made sovereign: I see radicle is written in Rust, which means dependencies on Cargo, the Rust toolchain, and so forth.
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?
> 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.
Honestly it's mostly lack of other users to interact with. It's my same problem with things like gitea. Someone needs an "account" to participate in your project.
I'm also not sure how to sync issues and pull requests with Github.
It's largely I haven't researched deeply enough yet.
AD: Pull requests are `patches` in radicle, when you clone a repository you create a git namespace for yourself from which you can edit to your hearts desire, you can then open patches to other repos via this mechanism.
Apparently currently "1 patch = 1 pull request of e.g. multiple commits" in Radicle.
That confusing, since in Git a patch usually refers to a single commit:
* git format-patch outputs 1 ".patch" file per commit.
* Its output also enshrines that, in the subject lines that appear e.g. on Linux mailing lists: "[PATCH 1/2]", meaning "one of two patches in a patch series".
(That said, `git format-patch --stdout` can concatenate multiple commits into a single output, but it does not offer to write those into a single .patch file by itself.)
So when reading "Patches", I was intuitively unnecessarily scared that the tool cannot handle whole branches, and flattens out all commits.
Unfortunately I won't have time for that; I just saw Radicle for the first time from this posting and wanted to drop-contribute what I think would reduce confusion for many people.
AD: The prefix is my initials :) - my only HN account is a shared one with a co-op organisation I work through. I use AD to distinguish who's commenting... however my co-workers have yet to use this account ha!
If you replace "AD:" by "Adrian from Endian writing:", people won't have to wonder what "AD" means, and waste their and your time on asking (you will probably get this question a lot otherwise).
Hello, I read the FAQ and didn't manage to find (perhaps my fault) if users had to store data they didn't explicitly/manually cloned; like Freenet. Is it the case?
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.
AD: You have control over what you seed, if you are a permissive node you accept all content on the network, but by default your local node will only seed what you instruct it too.
AD: Huh! I just wrote a utility cmd [1] this weekend to deal with restricting ssh keys to executing only commands that match a rule set via `ForceCommand` in `sshd_config` or `Command=""` in `authorized_keys`. I'm curious to see how susceptible it is to the aforementioned issues, it does delegate to `<shell> -c '<cmd>'` under the hood [2], but there are checks to ensure only a single command option argument `--` is passed (to mitigate metacharacter expansions) [3].
Note this tool is only intended to be another layer in security.
[AD] Oh wow! I've not found someone working on the same issue, I wrote a short paper on a method to identify remotely running software [1]. I'd love to get your opinion!
[AD] I've wrote a short paper on this; Remote Software Identification -- Zero Trust Remote Software Verification [1] after reading a blog post by GUIX - and I've provide PoC code in Go [2]. It utilises a hash chain log server side, of inputs and outputs, every response from server embeds the related hash chain entry, client side can request and replay the log and verify the response hash adds up to the hash they calculated.
