I think it would imply that it is a Turing incomplete language. So, it would not be able to express certain programs, but all the computation you can represent is mathematically shown to reduce to a termination point.
If you have the time, it would be great to see you trying out Radicle, even if it’s just for a mirror to start; then see how we can turn that into something more integrated!
I remember the day Rúnar told me he was going to work on this new language called Unison.
I have always thought it was an amazing project to set out on, and was paving the way for a new kind of paradigm. Super proud to see them release a 1.0 and I would love to say Unison is my go-to language in the near future!
I’m pretty sure one of the Zed founders wrote tree-sitter, so I’m sure there’s some overlap
It’s really cool to see tree-sitter unlock so many of these use cases. I love using [difftastic] for my diffing tool to get context aware diffs. So in the example from the article, the diff would highlight the `void` and `int` changes with a heavier background of red and green respectively
I believe the after change hovers over the before line. So if you go back to the video, e.g. at 27s in, there's a lightning bolt highlighting which line is going to be changed, then there's a box, with "tab" at the end, above the line, highlighting the change that will be performed :)
We're quite aware that Git is a distributed code collaboration tool, even trying out the email based flow in the past :)
You may notice that the title is "peer-to-peer code collaboration stack built on Git", emphasis on "built on". We're using Git as a storage and transport mechanism for code collaboration data. So we're building a local-first tool for the social data, e.g. patches and issues.
The Radicle project doesn't involve the crypto token, started by Radworks, in its technology.
It's also stated in the FAQ on the website (https://radicle.xyz/faq) that the project is funded by Radworks and also provides a link to the funding page.
I, for one, work on Radicle and what I care about is the data sovereignty and local-first code collaboration. We're building on top of Git to provide a local-first, extensible collaboration experience -- avoiding walled gardens like GitHub :)
As a project team, we only posted once on HN when we were announcing our v1.0 release candidates. The other two posts have been from other people outside of the organisation, so it's nice to see there's interest in the project but don't blame us for that kind of hype :')
At the moment there isn't any mechanism for that kind of drive-by action. The current mechanism for creating an issue requires that a Git reference is created (the COBs structure) for replicating by other nodes.
Perhaps in the future, a user could use a web interface for a Radicle node and they post it directly from their browser. Some questions about that would the verifiability of that action though. Definitely some food for thought here!
Git is just a mechanism for storing plain-text data as a series of commits. The underlying data are just blobs of bytes. So all data is Git data and Radicle takes full advantage of that.
The "special" data in Git would be `refs/heads`, `refs/remotes`, `refs/tags`, and the lesser known `refs/notes`. Radicle doesn't touch those directly, we still allow the use of Git tooling for working with that data.
It then extends on top of these by use `refs/rad` and `refs/cobs` for storing Radicle associated data, using all of Git's mechanisms that it provides to do so.
I'd like to note here that Radicle has defined our own version of issue and patch management, but they're not necessarily required to be used as part of the protocol. The protocol only defines that any and all COBs will be stored and replicated under the `refs/cobs` hierarchy.
If someone wanted to come along and define a way to embed Fossil wikis/issues as a COB then they could be replicated on the Radicle network and it's then up to application developers to load and interpret that data.
I think this is cool because it essentially allows developers to extend the Radicle ecosystem easily and define new workflows! However, that does not avoid our XKCD problem stated above ;P But hey, sometimes that's the beauty of these things -- we're given the power to define our own workflows and not locked into something everyone complains about coughGitHub branches PR flowcough
Yes, but the maintainers can be changed while also keeping the identifier stable.
Updates to the delegate set (read: maintainers) can be made, let's say adding a new delegate. This change is signed by a quorum of the current set of maintainers. This change is kept track of in the Git commit history, so these chain of actions can be walked from the root and verified at each point.
Similarly, a delegate can be removed, the project name changed, etc.
Forking is only necessary if there is a disagreement between maintainers that cannot be resolved so one of them goes off to create a new identifier to differentiate between the two. At this point, it's up to you to decide who you trust more to do a better job :)
Radicle developer here :) And yes you're completely right.
The current state of key management has A LOT left to be desired, because `did:key` has no rotation and so if you lose your key then it's game over. We decided to go with something simple first to allow us to develop the collaboration experience as much as possible -- we're a small team so it's hard to tackle all of the large problems all at once, while also getting an experience that's polished :D
Key management and a general "profile" is high on our priority list after we have properly launched. A few of us think DIDs (https://www.w3.org/TR/did-core/) are a good way forward. In particular, `did:keri` seems very interesting because its method involves a merkle-chain log, which can be easily encoded in Git. It includes key pre-rotation -- meaning there's a key that's available to help recover if something goes wrong. It can also delegate to other people, so you can allow the safety of your identity and key be improved by third-parties.
That said maybe there are other DID methods or other methods in general that might better suit. Or maybe we're able to build something that can be more general, and just needs to essentially resolve to a public/private key pair and we don't care after that.
Would definitely be interested in the communities thoughts here :) Or if someone who's got expertise in the area wants to chip in, hit us up ;)
> The reason for needing to not know the hash is for cases like tornado cash. The site and repo was taken down. There's a bunch of people sharing a codebase with differing hashes, you have no idea which is real or altered.
> This is also important for cases where the domain is hacked.
I think at some point you need to know some sort of root-of-trust to kick off the trusting process. I believe in this case, you would trust a certain DID or set of DIDs (i.e. a Tornado Cash developer's public key). You can clone their version of the project and the history of the project MUST be signed by their private key for it to be legitimate.
To clarify, in Radicle, a peer's set of references are always signed by their key and this data is advertised so that you can always verify, using their public key, that this data is indeed what this peer has/had in their Git history. If this ever diverges then any fetching from that peer is rejected.
We will benefit from jj's compatibility with Git for the time being, and seeing how that evolves.
Interoperating with jj's repository would likely be a bigger task and it is still evolving quite quickly itself.