Their whitepaper is an interesting read.
Most projects that try to build dynamic data on top of merkle trees / dags seem to be using Conflict Resolution Data Types (CRDTs) (peer-crdt, orbitdb, gun, repikativ, dat), instead they have gone for a Replicated State Machines (RSM) with a lisp/scheme like DSL.
This seems like an interesting alternative provided that there is a way to resolve conflicts when multiple peers add to the same graph. Conflict resolution doesn’t seem to be an issue for radicle as the owner of the repo (if I understand this correctly) is the one that needs to accepts patches and will have to republish on IPNS, thus simply appending new nodes to the DAG after accepting the patch instead of using the ones the contributor created. (I might really be off on this but I’d love to get how conflict resolution works if someone understands this better).
Owh and I love the ability to use the same language to query the RSM as well.
> Conflict resolution doesn’t seem to be an issue for radicle as the owner of the repo (if I understand this correctly) is the one that needs to accepts patches and will have to republish on IPNS
This isn't quite what happens. Anyone who is authorised to do
so (according to the semantics of the radicle code of the
machine) can accept patches. They do this by forming a valid
input (a radicle expression), with the correct signatures
etc. This input is then sent to the owner via pubsub, so you are
right that it is then the owner which republished on IPNS. The
owner doesn't have to do anything manually though, this is all
done automatically by the daemon. The assumption is that the
owner will republish anything that is correct according to the
machine's semantics, but it is true that the owner can censor
otherwise valid inputs.
This is awesome! Many people (including me) complain that Github is too centralized and closed source. AFAIK this is the first platform that integrates git and IPFS. It looks like it is built around the Git CLI. So another layer of abstraction.
One thing that stuck out to me is this line:
> Note that stack might take as much as 4GB of memory to build Radicle.
There doesn't seem to be an obvious way to remove content (like issues, merge requests or comments) easily from a project or ban contributors from participating, ie, ripe for abuse by 4chan or whoever wants to set the internet on fire today.
There is a line between censorship and a healthy culture in a project, I don't think asking for tools to moderate what people write into issues and being able to remove illegal content (like copyrighted movies or CP), is not censorship, especially because I'm not a government body nor do I have even remotely that power.
Giving me these tools empowers me to run the project how I like, not how someone who read the backcover of 1984 likes it (ie with no moderation tools at all).
If "censorship" is stopping people from spreading certain information, what do we call forcing people to spread certain information that they don't want to? I wish there was a word for that.
Generally speaking, censorship is about suppressing something with the intent that nobody can get access to it. Deciding not to forward information is not actually censorship because generally the original speaker can choose other avenues in which to spread their information.
I think it's interesting to imagine a situation where someone puts a political poster on their house. They live near a busy street and so the political poster gets a lot of views. Another person thinks this is unfair because they don't own a house (let alone a house near a busy street). They ask the house owner to display their political poster. The owner decides not to because they don't like the poster. Is that censorship?
Now imagine that our enterprising poor person decides to canvas the neighbourhood to see if someone else will post their poster. The person with the poster on their house thinks this will impede the success of the ideas on their poster and so canvases the neighbourhood asking others not to accept the poor person's poster. Is this censorship? If so, should we make a rule that the person with the house is not allowed to tell others not to post other posters? Is that censorship?
Now imagine that the government made a rule. Only those who own their own house may post posters. You may not ask others to post posters for you because it causes problems in the neighbourhoods. Is that censorship? They aren't trying to suppress any particular message. However, the end result is that poor people have no effective way of posting posters.
I understand that there is frustration if people don't cooperate to help you spread the message you want to spread. However, I don't think that in itself is censorship. It is especially frustrating when a group of people collude to deny you a cheap/popular platform to spread your message. I don't think even that is censorship, even though it's kind of a crap thing to do. Even if there are situations that arise that make it impossible for you to spread your message, that is not necessarily censorship, even though it is really, really frustrating. It's only when society actively tries to suppress any avenue for you getting your message out is it called "censorship".
TL;DR: Nobody owes you a free lunch, no matter how hungry you may be.
While it's true there's currently no easy way to do that, we've made the machines (the name we use for each instance of an issue, project or patch utility instance) upgradable by the maintainer [0], and each submission is already signed. So if it becomes a big problem, we can write up a little expression that adds banning, rate-limiting, or removes certain content, from the materialized view, and anyone who wants to use it can.
That said, the already-accepted content will still be in the logs of the machine, even if it doesn't show up at all in the materialized state.
That sounds like it could be an issue if illegal content is accidentally accepted, the owner of the repository would have to continue to share it and users might be at risk of downloading it, even if they don't see it.
That plus moderation tools couldn't cut down on people trying to bloat the repository.
I think the same “problem”
exists with GitHub, and the same solution exists here: the repo owner/ipns keyholder can rewrite history at will. Redacting information from the authoritative copy is possible.
Well with traditional git, you can use tools like BFG and remove files or rewrite history that might have accidentally contained a password or API key (sure you can change them, but it's also best to get rid of them in history). Since this is on top of IPFS, is that still possible, or are there cases where things will last forever?
As u/sneak pointed out, you can also completely remove things from the logs. It goes outside the semantics of the Radicle language itself, so it's not exactly first-class, but is possible.
Couldn’t you just solve this by requiring submissions to be signed with a key signed by another chosen trusted authority. This authority could either be the maintainer, or somewhere else which charges a nominal fee for a certificate.
Imagine someone posts illegal content to the repository. Now you can't remove it. Essentially you'll have to recreate the entire repository and you'll loose the issues, PRs and other stuff.
Correct, but generally, the law in your own legislation comes first, then the law in other countries, limited/directed by international laws and treaties.
That's an important point (if true), because an original goal of IPFS was to allow removal of illegal content to comply with (local?) laws. So if complying with that IPFS goal means the whole repo gets shut down, that seems intensely abusable.
This could have changed, but my initial impression was that you could "remove" content by blacklisting it at the http gateway, but if you used the IPFS native client instead of the gateway then the content was still accessible.
I thought this was clever--let the lawyers file takedown requests and feel pleased that they can't see the content anymore, but it's always there if you know where to look (as long as somebody still has it pinned).
This is probably the way to handle it in Radicle too, let the project maintainer provide a white/black list of issue hashes (something like a .issueignore, or .issueinclude file at the root) and have the client only bother fetching the ones on a list.
That seems to be the gift and curse of all decentralized systems. There really isn't a clearly defined red line between freedom of speech and moderation and I don't think there will ever be. Is it even possible to have a protocol or app mandate what is permissible content and what is not? And that is made even worse (imo) when humans come into play, as everyone's opinions and biases also affect the decision.
IMO the owner of the projects should be given those tools, they can decide whether or not to use them, either freedom of speech or moderation is in their own hands.
Given this is decentralized this puts even more power in the owner of a project to decide this than Github so I don't see this as an issue.
Decentralized systems can still have owners of property who allow and disallow certain uses. “Human bias” and “censorship” are completely irrelevant here.
You might be right on this. In my mind one of the key properties of decentralized systems/networks is censorship-resistance, which (again in my mind) means that everyone always has access to the full set of data and not a cut-down version that the "property owner" decided to arbitrarily allow.
Decentralized systems do still have benefits even when they can be moderated. I wonder if there are many projects that actually allow that?
Moderation powers scare me, but I do know that notabug.io , d.tube , and the upcoming HackerNoon 2.0 have this type of feature. Except it is called "curation" (technically, content can't really get deleted, but a curated homepage can certainly exclude content).
The good news is that the founders of all these apps are working towards user-configurable curation, so you could override who/what/how curation happens. I don't like moderation, but opting into a web-of-trust is, I think, an interesting area to explore.
No matter the good I want to come from decentralization, it certainly can be used for bad. However, its abuse should be less than centralized system, so hopefully that means real progress is happening.
>Decentralized systems do still have benefits even when they can be moderated. I wonder if there are many projects that actually allow that?
Most of them, at least the successful ones. It's a bit worrying to me that we seem to start talking about decentralized services as a theoretical concept instead of a reality of the internet.
Email is decentralized but every server typically has a bunch of rules to prevent abuse. Videogame servers used to be decentralized but still obviously attempted to limit cheating and allowed each admin to kick users and implement arbitrary restrictions and improvements. IRC allows mods in individual channels and ircops that can kline network-wide. The web itself is (?) decentralized but every server can arbitrarily decide what to host and not to host.
It's a bit odd to me that some people in this thread seem to assume that lack of moderation is an inescapable side-effect of a decentralized system, this is obviously not the case. You can't censor the network as a whole but you still have free reign on your server.
You're free to implement the rules you want on your node, the only risk is that you may end up being incompatible and fork from the rest of the network. That being said if the rules end up being useful and beneficial for the majority most people will use that version and the issue will be moot (e.g. people don't usually fork IRC servers to remove modding tools).
email and irc are both federated services and users depend on their server software or server admin to make sure weird content does reach them. In an actually decentralised system you must expect the client or protocol to deal with this.
IRC is admittedly not the best example since you can't usually join an IRC network "swarm" without approval.
I think email works though, anybody can spawn a postfix server and interact with the rest of the mesh immediately. I run my own email server that I fully control and I never had to ask anybody permission to do it.
I think it would make sense for Radicle to work somewhat similarly, anybody can spawn a repo, there's no central authority that can censor or alter any repo but the owner still has full control over it.
This is a joke. I think people just use the word decentralised as a blunt and nothing else matters. No access control, no problem it is decentralised. No content filtering, no problem it is decentralised. And so on. Decentralised is the new religion.
There already is access control. Only admins can accept patches, for instance (though a bug we've just made a fix for [0] meant if someone else tried doing it the entire patch system for that project would break). Programmatic content-filtering is really the bread-and-butter of Radicle. Ad-hoc content-filtering is a bit harder, but as I mentioned elsewhere still possible.
We store their public key on the machine. They can add (or remove) admins. Every input is signed, and (when relevant) the author is checked for authorization.
Radicle is a full-fledge (fledling of a) programming language, so you can really do as you wish with access control. Here's the module for authorization [0], and in this module [1] you can see an example of it being used.
That's the pros and cons of decentralization. It gives you a lot of freedom, but sometimes too much freedom is a gate for many issues like manipulation, pornography, spamming, low-quality content etc...
I don't think that's a problem. IPFS is content addressed so each added commit/issue/whatever added to the chain of a repositories state changes the head address. IPNS is then used to update a pointer to that head so you can address the whole repository with a fixed name. Only the owner of the repository can do that. Here's a bit more about how all that works: http://www.radicle.xyz/docs/index.html#radicle-p2p-architect...
I've read the docs but there is no obvious way you can actually remove an issue or PR from the repository once it's there, atleast not with the tools provided out of the box.
Yeah. I guess you're right in that case. Removing something once it has been approved previously sounds impossible indeed. I guess approval is a final decision. The only option possible (I guess) would be to hide content. But it would still need to be persisted to not break the chain.
There was a project, mango [0], that was very similar to this. In addition to using IPFS for storage, it used ethereum for things like permissions control. Unfortunately it hasn't been updated in a while, but perhaps this will bring some attention to it?
Very interesting. Does radicle use something like the git-remote-ipfs plugin to sync to an ipns address? Also, are objects duplicated over the filesystem, git and ipfs or have you found some way around that? I'm working a bit on a DVCS built on IPFS as a side project, but it's nowhere near usable (search for IPVC on github). The natural step after replicating basic git/hg features would be something like what radicle is doing with issues, pull requests etc.
If you want a good alternative to GitHub (though not decentralized other than the distributed properties inherent to git), use Amazon CodeCommit. No github politics/nonsense to deal with, just reliable hosting for git repositories accessible anywhere with a user control system via IAM that is very controllable.
Just a noob question here. IPFS doesn't guarantee that any data stored in it will be available for retrieval in future (unless lots of nodes want to cache it).
Why will anyone want to use IPFS for data storage without an availability and latency guarantee?
However, it seems like something that would need clever UI integration to really solve the problem. Any user oriented actions like github starring, reddit upvoting/saving, browser bookmarking, etc. might need to also do a pin?
We're definitely still in alpha - during the time we've been on HN, for example, we've discovered that the large amount of traffic projects were getting meant our timeouts were too short. Had we exclusively been using our own patch system for changes, it might have been hard to submit a fix! We turned on github issues again since if someone had a hard time installing or running, they wouldn't have been able to submit bug reports. And we still have breaking changes relatively often.
I'll take this opportunity to say again - this is alpha software, and not ready for production use!
How can anybody compare this to Github than? I want to maintain control over who can do what in my repo. If this solution does not support it than it is not an alternative of Github at all.
The owner still is responsible for accepting patches, etc.
Everyone (that has the hash) can see the repo, see and create patches and issues, but only the owner can accept/merge patches. Not sure about issues.
It does support it. In fact, it's much finer grained than Github. It's relatively easy to change things so e.g. patches to a certain file can only be submitted by people in a certain group, while other files anyone can change.
> There is no notion of access restriction for now at least as this is something missing from ipfs itself, check out radicle’s faq.
This isn't quite true. We already have an authentication and authorization mechanism on top of ipfs. So for instance, only admins/maintainers (of which there might be multiple ones) can accept patches.
(Being an admin/maintainer is different than being a machine owner - currently there can be only one owner. Currently owner has to be online for any new inputs to be processed, though reading should work if your data is replicated, and we've already built some tooling around making that easy.)
I really dislike the white paper format. If you print it out on paper and read it, it's easy. It's a terrible reading experience on mobile. Why does it need to be a pdf? At least publish 2 versions, an html version and a pdf version.
Their whitepaper is an interesting read. Most projects that try to build dynamic data on top of merkle trees / dags seem to be using Conflict Resolution Data Types (CRDTs) (peer-crdt, orbitdb, gun, repikativ, dat), instead they have gone for a Replicated State Machines (RSM) with a lisp/scheme like DSL.
This seems like an interesting alternative provided that there is a way to resolve conflicts when multiple peers add to the same graph. Conflict resolution doesn’t seem to be an issue for radicle as the owner of the repo (if I understand this correctly) is the one that needs to accepts patches and will have to republish on IPNS, thus simply appending new nodes to the DAG after accepting the patch instead of using the ones the contributor created. (I might really be off on this but I’d love to get how conflict resolution works if someone understands this better).
Owh and I love the ability to use the same language to query the RSM as well.
> Conflict resolution doesn’t seem to be an issue for radicle as the owner of the repo (if I understand this correctly) is the one that needs to accepts patches and will have to republish on IPNS
This isn't quite what happens. Anyone who is authorised to do so (according to the semantics of the radicle code of the machine) can accept patches. They do this by forming a valid input (a radicle expression), with the correct signatures etc. This input is then sent to the owner via pubsub, so you are right that it is then the owner which republished on IPNS. The owner doesn't have to do anything manually though, this is all done automatically by the daemon. The assumption is that the owner will republish anything that is correct according to the machine's semantics, but it is true that the owner can censor otherwise valid inputs.
This is awesome! Many people (including me) complain that Github is too centralized and closed source. AFAIK this is the first platform that integrates git and IPFS. It looks like it is built around the Git CLI. So another layer of abstraction.
One thing that stuck out to me is this line:
> Note that stack might take as much as 4GB of memory to build Radicle.
Is this normal for Haskell projects ?
4GB is a bit of an overestimate (it's probably more like 2.5GB) but yeah, Haskell project often consume a lot of memory when building.
That said, there are brew and deb packages!
What is the performance like?
I like the ideals in IPFS, but I would also be very surprised if it could compete with the performance I get from S3.
Let's be honest, our centralized solutions are mostly good enough :)
Cool! You might also want to checkout git over Secure Scuttlebutt: https://scuttlebot.io/apis/community/git-ssb.html
The design of SSB has been an inspiration for Radicle :) and we are aware of git-ssb.
Also worth mentioning GitCenter (here's a public proxy link https://zn.amorgan.xyz/1GitLiXB6t5r8vuU2zC6a8GYj9ME6HMQ4t/re...) which runs on top of ZeroNet as is already in use by a number of people. Notably ZeroNet's source code is also mirrored here.
It has issues/PRs and the like, and content can be deleted quite easily.
Supports SVN too apparently.
There doesn't seem to be an obvious way to remove content (like issues, merge requests or comments) easily from a project or ban contributors from participating, ie, ripe for abuse by 4chan or whoever wants to set the internet on fire today.
You know we're living in a dystopian future where the first complaint against an open source project is that it provides too few tools for censorship.
There is a line between censorship and a healthy culture in a project, I don't think asking for tools to moderate what people write into issues and being able to remove illegal content (like copyrighted movies or CP), is not censorship, especially because I'm not a government body nor do I have even remotely that power.
Giving me these tools empowers me to run the project how I like, not how someone who read the backcover of 1984 likes it (ie with no moderation tools at all).
Access control is not censorship.
If "censorship" is stopping people from spreading certain information, what do we call forcing people to spread certain information that they don't want to? I wish there was a word for that.
Generally speaking, censorship is about suppressing something with the intent that nobody can get access to it. Deciding not to forward information is not actually censorship because generally the original speaker can choose other avenues in which to spread their information.
I think it's interesting to imagine a situation where someone puts a political poster on their house. They live near a busy street and so the political poster gets a lot of views. Another person thinks this is unfair because they don't own a house (let alone a house near a busy street). They ask the house owner to display their political poster. The owner decides not to because they don't like the poster. Is that censorship?
Now imagine that our enterprising poor person decides to canvas the neighbourhood to see if someone else will post their poster. The person with the poster on their house thinks this will impede the success of the ideas on their poster and so canvases the neighbourhood asking others not to accept the poor person's poster. Is this censorship? If so, should we make a rule that the person with the house is not allowed to tell others not to post other posters? Is that censorship?
Now imagine that the government made a rule. Only those who own their own house may post posters. You may not ask others to post posters for you because it causes problems in the neighbourhoods. Is that censorship? They aren't trying to suppress any particular message. However, the end result is that poor people have no effective way of posting posters.
I understand that there is frustration if people don't cooperate to help you spread the message you want to spread. However, I don't think that in itself is censorship. It is especially frustrating when a group of people collude to deny you a cheap/popular platform to spread your message. I don't think even that is censorship, even though it's kind of a crap thing to do. Even if there are situations that arise that make it impossible for you to spread your message, that is not necessarily censorship, even though it is really, really frustrating. It's only when society actively tries to suppress any avenue for you getting your message out is it called "censorship".
TL;DR: Nobody owes you a free lunch, no matter how hungry you may be.
Actually in a modern democracy I am owed a free lunch.
Damn. Gotta get me one of those lunch tickets!
https://www.fns.usda.gov/snap/supplemental-nutrition-assista...
While it's true there's currently no easy way to do that, we've made the machines (the name we use for each instance of an issue, project or patch utility instance) upgradable by the maintainer [0], and each submission is already signed. So if it becomes a big problem, we can write up a little expression that adds banning, rate-limiting, or removes certain content, from the materialized view, and anyone who wants to use it can.
That said, the already-accepted content will still be in the logs of the machine, even if it doesn't show up at all in the materialized state.
[0] This is based on the eval-redefinition we describe here: https://ipfs.io/ipfs/QmadmGA6mBWZ93Wv4XKuCu9wdPf7Da8pjH3Corz...
That sounds like it could be an issue if illegal content is accidentally accepted, the owner of the repository would have to continue to share it and users might be at risk of downloading it, even if they don't see it.
That plus moderation tools couldn't cut down on people trying to bloat the repository.
I think the same “problem” exists with GitHub, and the same solution exists here: the repo owner/ipns keyholder can rewrite history at will. Redacting information from the authoritative copy is possible.
Well with traditional git, you can use tools like BFG and remove files or rewrite history that might have accidentally contained a password or API key (sure you can change them, but it's also best to get rid of them in history). Since this is on top of IPFS, is that still possible, or are there cases where things will last forever?
> That said, the already-accepted content will still be in the logs of the machine, even if it doesn't show up at all in the materialized state.
Which is still a disaster from a data privacy perspective (think GDPR requirements for deleting PII).
As u/sneak pointed out, you can also completely remove things from the logs. It goes outside the semantics of the Radicle language itself, so it's not exactly first-class, but is possible.
Couldn’t you just solve this by requiring submissions to be signed with a key signed by another chosen trusted authority. This authority could either be the maintainer, or somewhere else which charges a nominal fee for a certificate.
This seems very much like a feature, not a bug.
Imagine someone posts illegal content to the repository. Now you can't remove it. Essentially you'll have to recreate the entire repository and you'll loose the issues, PRs and other stuff.
Illegal according to whom?
The country you live in.
With the continued over-reach by some first world Governments, it may not need to be illegal just in your jurisdiction.
Correct, but generally, the law in your own legislation comes first, then the law in other countries, limited/directed by international laws and treaties.
That's an important point (if true), because an original goal of IPFS was to allow removal of illegal content to comply with (local?) laws. So if complying with that IPFS goal means the whole repo gets shut down, that seems intensely abusable.
This could have changed, but my initial impression was that you could "remove" content by blacklisting it at the http gateway, but if you used the IPFS native client instead of the gateway then the content was still accessible.
I thought this was clever--let the lawyers file takedown requests and feel pleased that they can't see the content anymore, but it's always there if you know where to look (as long as somebody still has it pinned).
This is probably the way to handle it in Radicle too, let the project maintainer provide a white/black list of issue hashes (something like a .issueignore, or .issueinclude file at the root) and have the client only bother fetching the ones on a list.
That seems to be the gift and curse of all decentralized systems. There really isn't a clearly defined red line between freedom of speech and moderation and I don't think there will ever be. Is it even possible to have a protocol or app mandate what is permissible content and what is not? And that is made even worse (imo) when humans come into play, as everyone's opinions and biases also affect the decision.
IMO the owner of the projects should be given those tools, they can decide whether or not to use them, either freedom of speech or moderation is in their own hands.
Given this is decentralized this puts even more power in the owner of a project to decide this than Github so I don't see this as an issue.
Decentralized systems can still have owners of property who allow and disallow certain uses. “Human bias” and “censorship” are completely irrelevant here.
You might be right on this. In my mind one of the key properties of decentralized systems/networks is censorship-resistance, which (again in my mind) means that everyone always has access to the full set of data and not a cut-down version that the "property owner" decided to arbitrarily allow.
Decentralized systems do still have benefits even when they can be moderated. I wonder if there are many projects that actually allow that?
I agree that decentralized systems should make things more open/free and censorship-resistant.
However, cryptography can certainly be used to restrict access or add moderation features.
For example, here is a demo of a P2P LinkedIn with ACL: https://www.youtube.com/watch?v=ZiELAFqNSLQ
Moderation powers scare me, but I do know that notabug.io , d.tube , and the upcoming HackerNoon 2.0 have this type of feature. Except it is called "curation" (technically, content can't really get deleted, but a curated homepage can certainly exclude content).
The good news is that the founders of all these apps are working towards user-configurable curation, so you could override who/what/how curation happens. I don't like moderation, but opting into a web-of-trust is, I think, an interesting area to explore.
No matter the good I want to come from decentralization, it certainly can be used for bad. However, its abuse should be less than centralized system, so hopefully that means real progress is happening.
>Decentralized systems do still have benefits even when they can be moderated. I wonder if there are many projects that actually allow that?
Most of them, at least the successful ones. It's a bit worrying to me that we seem to start talking about decentralized services as a theoretical concept instead of a reality of the internet.
Email is decentralized but every server typically has a bunch of rules to prevent abuse. Videogame servers used to be decentralized but still obviously attempted to limit cheating and allowed each admin to kick users and implement arbitrary restrictions and improvements. IRC allows mods in individual channels and ircops that can kline network-wide. The web itself is (?) decentralized but every server can arbitrarily decide what to host and not to host.
It's a bit odd to me that some people in this thread seem to assume that lack of moderation is an inescapable side-effect of a decentralized system, this is obviously not the case. You can't censor the network as a whole but you still have free reign on your server.
You're free to implement the rules you want on your node, the only risk is that you may end up being incompatible and fork from the rest of the network. That being said if the rules end up being useful and beneficial for the majority most people will use that version and the issue will be moot (e.g. people don't usually fork IRC servers to remove modding tools).
email and irc are both federated services and users depend on their server software or server admin to make sure weird content does reach them. In an actually decentralised system you must expect the client or protocol to deal with this.
IRC is admittedly not the best example since you can't usually join an IRC network "swarm" without approval.
I think email works though, anybody can spawn a postfix server and interact with the rest of the mesh immediately. I run my own email server that I fully control and I never had to ask anybody permission to do it.
I think it would make sense for Radicle to work somewhat similarly, anybody can spawn a repo, there's no central authority that can censor or alter any repo but the owner still has full control over it.
Not at all. There are plethora of services that are decentralized and have proper access control.
This is a joke. I think people just use the word decentralised as a blunt and nothing else matters. No access control, no problem it is decentralised. No content filtering, no problem it is decentralised. And so on. Decentralised is the new religion.
There already is access control. Only admins can accept patches, for instance (though a bug we've just made a fix for [0] meant if someone else tried doing it the entire patch system for that project would break). Programmatic content-filtering is really the bread-and-butter of Radicle. Ad-hoc content-filtering is a bit harder, but as I mentioned elsewhere still possible.
[0] https://github.com/radicle-dev/radicle/pull/552
Where do you store who is ad admin?
We store their public key on the machine. They can add (or remove) admins. Every input is signed, and (when relevant) the author is checked for authorization.
What if I need more fine grained access control?
Radicle is a full-fledge (fledling of a) programming language, so you can really do as you wish with access control. Here's the module for authorization [0], and in this module [1] you can see an example of it being used.
[0] https://github.com/radicle-dev/radicle/blob/master/rad/prelu... [1] https://github.com/radicle-dev/radicle/blob/master/rad/monad...
That's the pros and cons of decentralization. It gives you a lot of freedom, but sometimes too much freedom is a gate for many issues like manipulation, pornography, spamming, low-quality content etc...
There is no reason why a decentralized tool cannot have moderation tools, especially one like this where there is a clear owner of a repository.
I don't think that's a problem. IPFS is content addressed so each added commit/issue/whatever added to the chain of a repositories state changes the head address. IPNS is then used to update a pointer to that head so you can address the whole repository with a fixed name. Only the owner of the repository can do that. Here's a bit more about how all that works: http://www.radicle.xyz/docs/index.html#radicle-p2p-architect...
I've read the docs but there is no obvious way you can actually remove an issue or PR from the repository once it's there, atleast not with the tools provided out of the box.
Yeah. I guess you're right in that case. Removing something once it has been approved previously sounds impossible indeed. I guess approval is a final decision. The only option possible (I guess) would be to hide content. But it would still need to be persisted to not break the chain.
There was a project, mango [0], that was very similar to this. In addition to using IPFS for storage, it used ethereum for things like permissions control. Unfortunately it hasn't been updated in a while, but perhaps this will bring some attention to it?
[0] - https://github.com/axic/mango
Very interesting. Does radicle use something like the git-remote-ipfs plugin to sync to an ipns address? Also, are objects duplicated over the filesystem, git and ipfs or have you found some way around that? I'm working a bit on a DVCS built on IPFS as a side project, but it's nowhere near usable (search for IPVC on github). The natural step after replicating basic git/hg features would be something like what radicle is doing with issues, pull requests etc.
It would be good if there was a mention of what IPFS is either in the title or their page.
I assume it's this distributed file system called InterPlanetary File System.
https://github.com/ipfs/ipfs
Yes that’s it.
Radicale is also the name of a great caldav/carddav server
There's a one letter difference in the name-
> Radicle > 1 : the lower part of the axis of a plant embryo or seedling:
'Decentralized Github' is an oxymoron because the 'hub' means a centralized place where people come to collaborate and git is already decentralized.
If you re-read the title, it's positioned as an /alternative/ to Github with a non-centralized collaboration model.
The website is a work of art, really digging the details!
I agree. Using the garden for tutorials is really cute and fun as well.
If you want a good alternative to GitHub (though not decentralized other than the distributed properties inherent to git), use Amazon CodeCommit. No github politics/nonsense to deal with, just reliable hosting for git repositories accessible anywhere with a user control system via IAM that is very controllable.
Just a noob question here. IPFS doesn't guarantee that any data stored in it will be available for retrieval in future (unless lots of nodes want to cache it).
Why will anyone want to use IPFS for data storage without an availability and latency guarantee?
The low level answer is that you can pin content to the cache so it won't be evicted: https://docs.ipfs.io/guides/concepts/pinning/
However, it seems like something that would need clever UI integration to really solve the problem. Any user oriented actions like github starring, reddit upvoting/saving, browser bookmarking, etc. might need to also do a pin?
Is anyone else as amused as I that their "Source" link leads to GitHub?
Same with Gogs and Gitea. I think GitLab was as well at one point.
It’s popular, so it makes sense to gain exposure. At least initially.
We're definitely still in alpha - during the time we've been on HN, for example, we've discovered that the large amount of traffic projects were getting meant our timeouts were too short. Had we exclusively been using our own patch system for changes, it might have been hard to submit a fix! We turned on github issues again since if someone had a hard time installing or running, they wouldn't have been able to submit bug reports. And we still have breaking changes relatively often.
I'll take this opportunity to say again - this is alpha software, and not ready for production use!
I get that, I just find it funny. GitHub is certainly a good starting place.
These flowers are like something out Alien. Scares the heck outa me.
all of the UI choices on the page are decentralized
How do I give access to contributors to my Rad projects?
You should only have to give them the ipfs hash that you get when initializing your repo.
There is no notion of access restriction for now at least as this is something missing from ipfs itself, check out radicle’s faq.
Should be solvable using techniques from https://notabug.io/
How can anybody compare this to Github than? I want to maintain control over who can do what in my repo. If this solution does not support it than it is not an alternative of Github at all.
The owner still is responsible for accepting patches, etc. Everyone (that has the hash) can see the repo, see and create patches and issues, but only the owner can accept/merge patches. Not sure about issues.
It does support it. In fact, it's much finer grained than Github. It's relatively easy to change things so e.g. patches to a certain file can only be submitted by people in a certain group, while other files anyone can change.
> There is no notion of access restriction for now at least as this is something missing from ipfs itself, check out radicle’s faq.
This isn't quite true. We already have an authentication and authorization mechanism on top of ipfs. So for instance, only admins/maintainers (of which there might be multiple ones) can accept patches.
(Being an admin/maintainer is different than being a machine owner - currently there can be only one owner. Currently owner has to be online for any new inputs to be processed, though reading should work if your data is replicated, and we've already built some tooling around making that easy.)
Love it. Next step.
So..git?
I really dislike the white paper format. If you print it out on paper and read it, it's easy. It's a terrible reading experience on mobile. Why does it need to be a pdf? At least publish 2 versions, an html version and a pdf version.
Thank you for your feedback. That’s a good idea. I’ll open an issue for it. :)