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.
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.
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 ?
That said, there are brew and deb packages!
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 :)
It has issues/PRs and the like, and content can be deleted quite easily.
Supports SVN too apparently.
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.
 This is based on the eval-redefinition we describe here: https://ipfs.io/ipfs/QmadmGA6mBWZ93Wv4XKuCu9wdPf7Da8pjH3Corz...
That plus moderation tools couldn't cut down on people trying to bloat the repository.
Which is still a disaster from a data privacy perspective (think GDPR requirements for deleting PII).
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 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).
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.
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.
 - https://github.com/axic/mango
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.
Yes, what you specifically want might not be implemented but it's been explained how it could be implemented. Rather than being constructive and trying to explain what kinds of access control should be included by default, you're dismissing the entire project because it doesn't come with batteries included.
Also, access control is hardly one of GitHub's largest features. It's also quite interesting you think content moderation is necessary for a GitHub-like product to be useful at all -- GitHub didn't have issue moderation (as in, deletion) until <6 months ago in November of last year! Moderation of comments and threads came earlier, but it took a long time for them to be implemented. And in their case everything is in a centralised database -- there isn't a novel technical solution required to delete a couple of rows in a database.
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).
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.
I assume it's this distributed file system called InterPlanetary File System.
> 1 : the lower part of the axis of a plant embryo or seedling:
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?
I'll take this opportunity to say again - this is alpha software, and not ready for production use!
It’s popular, so it makes sense to gain exposure. At least initially.
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.)