HN user

endiangroup

111 karma

website: https://endian.io

Posts2
Comments60
View on HN

AD: Thanks for engaging in a constructive way!

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: 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?

AD: I'll take a stab, but I am a new joiner!

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.

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.

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!

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.

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.

[1] https://github.com/endiangroup/cmdjail [2] https://github.com/endiangroup/cmdjail/blob/main/main.go#L30... [3] https://github.com/endiangroup/cmdjail/blob/main/config.go#L...

[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.

[1] https://gist.github.com/adrianduke/ab40044ccee16804a9d0b2b77... [2] - https://gist.github.com/adrianduke/676ee1ffb88f4489b31aebf5e...

To be clear I didn't say "don't model" - models can have value but all models are wrong because the map is not the territory. That's a first order problem, any representation of something is not the thing itself and bears no requirement to continuously and accurately represent it.

Another first order problem is you must chose from all the data that is perceivable what is pertinent to model because you can't perceive and model it all (at least not in complex systems) - that 'is perceivable' and 'choosing what is pertinent' act as filters that rarely are questioned. How do you know that 'what is pertinent' hasn't changed if your only way to reason about the system is through the model itself? How do you know you aren't perceiving something more relevant? Designing models to be sensitive to what we mean and not what we've stated is a very hard problem. The state space of reality is far bigger than we can sense and store.

A second order problem lies in human propensity for low energy states, when given a model or a metric we'll champion it as the truth or the way because it is easier than facing the complexity - but complex systems are crafty they adapt continuously. For example, your boss wants 100% test coverage and a dashboard has been created to report it to them... Fine, we'll test the getters and setters, we'll modify the dashboard code to ignore certain files, we'll write pointless tests that just exercise code but make no assertions... etc. They likely won't check provided the dashboard keeps reporting what they want to see.

Another second order problem is in complex adaptive systems the act of measurement changes the behaviour of the system itself. We know this intuitively, pull out a camera and start recording some strangers who were going about their business.

As for "what should we do instead" - complexity is all about context dependence... so it depends? If you are in a complex adaptive system, get involved! You can't know it all - so have fun with it.

Having studied complexity from a computational perspective (via Santa Fe Institute and 1st wave Cybernetics) and a natural sciences one (via Dave Snowden and Alicia Juarrero) my preference is to stay away from modelling complex systems particularly complex adaptive ones. There is value in modelling, but heed the advice that all models are wrong. If you want to understand why, take a look at Steven Wolfram's Computational Irreducibility and Dave Snowden's Cynefin framework.

As for your interest in self-assembly and emergence I would highly recommend Alicia Juarrero's Dynamics in Action and Context Changes Everything - they are both tapping biological sciences to update and better inform our views of the world in deeply meaningful ways. The former changes our notion of cause-and-effect as the driving force in complex systems, stepping away from the Newtonian billiard ball frame. The latter expands on it talking about how constraints underpin the actions and dynamics in complex systems.

I'd agree that I'd love to see some convergence eventually in the complexity sciences world - but it is a new science relatively speaking - the divergence is a positive property in my opinion!

Keep up the energy, keep writing and keep researching! I enjoyed your post, it reminded me of the excitement I have for the field as a whole and the thirst I had for very similar questions! I wouldn't of guessed you were a 16yr old had you not stated it. Be prepared to have fundamental views changed and get comfortable with uncertainty!

AD: Yes, what a wonderful application of tech. I very much enjoy seeing these hardware <> software open source projects. Congratulations on developing a finished project.

AD: I have to disagree with the assumption there are only 3 communication forms (work, async, sync) - it's not hard to fathom a counter example such as Pairing where-in synchronous communication is necessary for the pair's flow state to emerge but they are "working as communication". Likewise there is an assumption here that meetings don't create flow states or that they don't contribute to "work as communication". Not all engineering is writing code and there should be some amount of back-pressure for writing the right code not just writing any code.

However I do agree with a general mentality of do > say which I believe this article is trying to allude to.

SEEKING CO-FOUNDER | Recruitment Tech | CEO/Sales | UK/EU/US | Pre-Seed

I'm a co-founder of gethigher.io, we provably increase the signal to noise ratio for open market recruiting at a lower cost point than agencies. We put this down at the end of covid due to spending too much of our own money with not enough results and now I'm picking it back up. I'm spending 2 days a week on it technically to get it ready to niche in the crypto space (having just had a successful role and candidate feedback), I'm not a sales person and have a proven record of it. However I am a 10+ year developer.

Let's chat - adrian@gethigher.io.

Thanks