I'm impressed and I see potential on this one. I tried different ones over time but most fail at on-boarding. This was seamless and really easy. In about 2 minutes I successfully shared my project and followed known projects. This means this mvp works and it let me craving for more, I want to use this! I want issues and PR support to prove this can effectively work as a github replacement to me.
Now, the downside of this mvp is that there is no project discovery in the client itself. We need to go search for projects in a browser, in this page http://seedling.radicle.xyz/ which is a bit confusing. Considering the client itself is electron, it could at least, open this page for us somewhere. Or, we could at least have a less "noisy" seedling page focused on search and I would not even know it wasn't part of the client itself.
Overall, awesome project. I really hope it will grow and add the missing essential features. If I could vote, with priority these would be:
- project discovery integrated in the client
- issues support
- pr support
- multiple identities
Thanks for the feedback! The priorities you mention are very close to our own, and we have already started working on some of them. We will definitely be integrating discovery more closely into the app in the long run.
Recently I started a personal project to enable storing issues in the git repository itself. Then I discovered git-bug which, though lacking a good UI, has the data formats nailed almost perfectly in my opinion.
I highly recommend considering using git-bug natively for Radicle's issue tracking system. It seems perfect for the task.
I was very interested but unfortunately my experience was quite opposite. I launched the app image on Pop_OS but couldn't sign up no matter which user name i chose (even resorted to random strings) - finally just gave up.
I came here to say just the opposite. The first thing I did when seeing the frontpage was to leave. It just felt overcrowded, unreadable and aggressive to me.
It's fun to see how different our opinions can be about this kind of things, I really didn't expect it in this case but here we go :)
I think page design standards need drastic changes, but to be honest I thought this page was broken the first couple of times I visited. I'm still not convinced there isn't some broken elements involved in its appearance.
That being said, I'm all for distributed systems so I hope for the best with this (without meaning to imply anything about it one way or another relative to other similar things that have been developed).
this is just me, but I'm honestly way more interested in this design post than I am about the product itself.
love the design - it's honestly something I've never seen before (at least, not in the context of software). I love how it rejects the tired old aesthetic of the "software tool front page" and goes in a totally different direction while still getting the point across.
I like the sketch of the first design presented there. It seems to fit with the product. Unfortunately, the cult-route they went with produced a busy page with lots of animation that distracts the reader. Also, overlapping headings with animations and changing colors immensely reduces readability.
If it weren't overly animated and the headings were legible, this design might actually be pleasantly nostalgic. But in its present state, it makes me wish for old radicle, when it was built on ipfs and had no GUI. The overt use of animation is exactly how I tend to think of unnecesary GUIs.
The main site page is just awful. It's amateurish, image/animation heavy to no value, almost negligable information. They may have something good but the site's just obscuring it.
I think it does a good job listing project ideas / features / roadmap and is a pleasant step away from the bland corporate brands. Love the esthetic. You just can't satisfy everyone.
Edit: perhaps more importantly, I have to gain a feeling for the product, to work out whether it's worth the perhaps nontrivial time evaluating it.
If I'm presented with this what it indicates to me, rightly or not, is that the product is image-led, the project is perhaps childish if the website is (clips from ghost in the shell?), fails to understand technical load (the website's bloated, what does it say about technical competence of the company) and whatever.
I don't care about corporate blandness, I need solid info, directly in front of me, and not having my eyes pulled away by flicker.
I could be completely getting the value of this project wrong but first impressions suggest I may well be wasting my time with it.
I don't understand how people think this is damning with no further context, especially on a forum presumably full of technical people. Virtually all of that (>9MB) are its gifs.
9MB of dozens of analytics.js files? Sure, awful.
9MB of gifs and <1000KB of html/css on a landing page? Who cares.
Btw, for lack of a kinder word off the top of my head, your rant about some images on the landing page is very juvenile. The tone of "hmm, it would be a shame if your design choices made me assume you were technically incompetent and a waste of my time :/" is really toxic.
Everyone here would understand what you mean if you just said the landing page was over the top for you. Fine. OP would know that a bold design to be divisive. And frankly some self-awareness on your part would help temper your reaction here instead of dramatizing it and sounding wounded.
Similarly, claiming that a project interested you but you couldn't even get past a landing page because it had some gifs is really just your loss, not anybody else's. Once again, had you just said "I wish there was a more informative page" (which is certainly a fair ask), someone could have linked you to https://docs.radicle.xyz/docs/what-is-radicle.html.
I know that now it seems like I'm the one overreacting, but your comment has some tropes of really bad communication habits that we tend to think are just part of internet discourse, but they aren't doing you justice.
I care. Wasting other people's resources is bad manners and contributes to a culture where waste is acceptable.
> waste of my time :/" is really toxic.
It was honest feedback. If others feel the same way the product marketing team is making a potentially serious mistake. Give me info, not anime android animations. It wasn't toxic.
> but you couldn't even get past a landing page because it had some gifs is really just your loss, not anybody else's.
If other people feel the same way, it very definitely stops being my problem and becomes the product's problem as people get turned off it. That was a core point you missed.
> but your comment ... but they aren't doing you justice
Thanks (genuinely) but I stand by this. It said what was wrong (IMO). it said what I wanted (again IMO), it was honest if blunt feedback the marketeers could use to decide if my point had merit (if they can admit they might have been wrong).
We differ but I appreciate your constructive feedback.
Especially for a FOSS project! Usually they tend to go with a default theme with the most drab design. As an engineer, I sympathize with the effort needed to make it look good though.
Very cool design. Matches well with the name. In my mind, Radicle invokes the design of the 90s (skids, grunge, hip-hop). This isn't quite that but it still works.
Totally agree, design today takes itself way too seriously to the point that it all looks like it came from the same corporate hell hole. This is a breath of fresh air.
the site design is cool. hosting it on GitHub is ironic, though. could it instead just be hosted via radicle? (mirrored to GitLab, GitHub, BitBucket, SourceForge, Savannah, ...)
Nice design, but I couldn't understand anything. I have a 21' screen and it way to wide. Our peripheral vision was made for motion, if you want human attention, put it in the center!
I can only digest the content properly if I stand a couple of meters away
At first I thought it was broken as I opened in mobile and it was very confusing. Otherwise, on desktop it looks funky, but fine - not awesome but not bad.
We kind of need this yesterday... what's the point of having a decentralized git if the issues are centralized at Github? (which, not to make too fine a point of it, is owned by Microsoft). Even if you host your own Gitlab, there is always that day when the hard drive of the server fails and the ops have to spend a weekend restoring backups while changing hosting company because who crashes the hard-drive of an expensive VPS anyway...
I hope Radicle gets a lot of funding and tons of adoption.
We use Github and we are not that interested in the decentralized aspects of git itself.
The low-friction UX and integration of issues/PRs/code makes it lightyears easier to ramp new developers than if I had to sit down and also explain Jira & Jenkins to them. The fact that git is centralized or decentralized crosses our minds precisely zero times per week.
In the absolute worst case where Microsoft somehow loses everyones' issue/PR/project data (assuming non-enterprise cloud hosted account), we could still rebuild with whoever has the latest master copy on their local. Presumably, one of our developers must have made the latest commit so this should work out always. We have a process where we include the issue numbers in our commits, so it would be possible to reconstruct a large portion of these with inference across commit history. Personally, I trust Microsoft to safeguard our business data more than I trust our 7 person team w/ a $2000/m AWS budget.
Ultimately, I think the objective of making all things around your source control technology look & talk like your source control technology is a huge mistake. Issues and code are completely orthogonal things that intersect in very narrow ways. These intersections are hugely valuable, but we are not interested in aligning the planes of functionality.
this is naïve. the problems being addressed do exist, independent of whether this particular solution will work. that’s great that the status quo is working for you, but it’s silly to then assert that progress cannot be made.
Well maybe our "naive" approach might be worth investigating. Because we put so little time into ridiculous missions like "distributed issues because git is also distributed", we are able to focus more on the product, customers, and processes. You know, things that actually drive business value and pay out everyones' bonus checks at the end of the year.
We have actually considered doing a complete in-house implementation of the things that GitHub handles, because we do already have an in-house management system that integrates with GitHub's API. But, we realized that we would then be in the business of maintaining what is effectively the GitHub product for a market size of 1 customer.
i’m saying it’s ok to be pragmatic and fully accept that you are Microsoft’s target demographic. they’re solving the annoying bits so you can focus on what’s important to you.
but, that’s not the end of the story. there may likely be gains found with new innovations.
companies like github are not incentivized to revolutionize “what works”. they’re incentivized to get you to rely increasingly on their services. and as long as that works for you, great!
i’m just saying, don’t discount efforts made to make github obsolete.
The nerds (I say that will all due respect) will fight your stance on this until the end of time, but of course you're correct. There have been discussions of distributed GitHub since the day the website launched, but the concept will never take off. 99.99% of developers understand the tools are a means to an end, not the thing worth focusing on.
> and pay out everyones' bonus checks at the end of the year
Yes. This is understated. Poor(financially) developers need to make money with lowest resistance(cost). Then, when you have enough for yourself and family, you can help or join rebels to fight for whatever you think is right.
Disclaimer: I love Github. From a commercial development standpoint (ie. my day job), it's fantastic.
BUT: What a lot of developers, myself included, feel like is the source control in git is great. The project management tools (issues, actions, etc...) require centralization of certain processes, that for some projects (open and closed source), don't fit well. Sometimes the 'how it works' is a bad fit. Other times, it's where it has to be to work. For example, running CI on a container on Azure from actions. Yes you can move where it runs. But for some projects, localhost is where that should happen. I'm really happy to see people working on this, because it will be just as transformative as git and Github has been.
I argue that centralization of certain processes is the entire point. How the hell are you going to manage a complex software project if everyone has a different version of the issues pertaining to it? Simply seeing an issue comment instantly update in GitHub as I am scrolling through has saved me tons of aggregate hours in wasted time on changing requirements.
First, I'm not arguing :-), just sharing. If I'm using fossil, I just do. Fossil is built by the people behind sqlite, and issues, wikis, etc... all of the pm stuff is baked in. Tickets that are referenced in check-ins are synced. This improves on github: if another dev has worked on a ticket and their branch hasn't merged yet, the ticket update is visible. Fossil also allows for heirarchal management structures, and so on. Incidentally, fossil's timeline is incredible.
Not saying that fossil is going to replace git/github. Probably not, but there are ways to solve simple information management problems that don't require a centralized, subscription service. By eliminating that, you open the door to much innovation... In the meantime, I've got a pull request or two to review over on Github.
i think fossil has the better architecture and it would probably take off if the baked in webapp were as polished as github. somebody should fork fossil and make a github clone.
I always find it comically ironic how the industry basically centralized a version management system (git) that was inherently designed to be decentralized. "Git is so great! Let's add these higher level project management features but let's do it in a centralized model!"
the industry aggressively seeks centralization. One browser always ends up taking huge amounts of market share. A small number of sites end up being hubs for large amounts of activity. We then spend forever trying to put the toothpaste back in the tube - federated social networks and chat, stuff like this.
I don't think that's any more ironic than it is to point out that LLVM is backend agnostic, yet we always end up hooking it up to backends that lock the end result to a specific architecture. It's not ironic; it's the advantage of the design.
In git's case, its decentralized nature ends up being an advantage because it decouples centralization from the VCS itself, which has allowed the centralized aspects of code and project management to evolve independently and be tuned to specific use cases.
I think the centralization comes from convenience. Building a good, decentralized UX is a lot harder than making a centralized one (evidence: almost every attempt at P2P networks.)
This was attempted multiple times in the past. None succeeded, in large parts because at a fundamental level issues are a synchronisation point, making issues part of the repository adds overhead and complexity but doesn't really give you anything, and furthermore it increases complexity for reporters.
All the issues, wiki, PR review are stored in Git as well. You still need a Pagure instance (that you can self host if you want) to provide the web ui, but you can easily just clone the repo and put it to a different instance, keeping all your metadata.
I know of an attempt to implement an approach to track issues and code in a decentralized manner with SIT[0]. Unfortunatlely the project seems to be dead.
- We are now working on the governance and collaboration workflows that will enable transparency in open source development and provide the stakeholders to have a say in the direction of the project.
I'm not sure I see the point of building a complex platform with governance and whatnot. What I want is an easy way to publish my projects and for other people to contribute, I need something more like email (independent, self-hosted servers with a well defined protocol to communicate between them) than Facebook.
I don't care about the governance of my git remote, or getting money out of it. I care about it being reliable, fast and simple. If I'm unhappy with it I want to be easily able to switch to a different host, or create my own.
Frankly I would be perfectly fine with the current situation where you have a bunch of effectively centralized code hosting solutions (github, gitlab, bitbucket etc...) if you could trivially move your project from one to an other. For the code it's easy, git is built that way. For issues, PRs and the like it's trickier.
For me that's the problem that needs solving, I don't need an ultra complicated blockchain-powered solution where people can vote for the font of the UI with cryptotokens.
At a glance, and if I understand it correctly, Radicle seems more pragmatic in that way. Cryptocurrency is used for donation and securing entries in the global namespace in a decentralized way, the rest is just a bunch of standalone servers. Then you can decide to host your code on an existing instance or spawn your own. A bit like how Mastodon works for instance.
You might be interested in https://github.com/MichaelMure/git-bug. It stores issues directly in the git repository so the whole issue tracker is as distributed as the rest of your code. I can't speak to the UX though.
The best solution from my perspective for the community would be to have a standard that handles issues/prs and the like that could be taken from one code hosting solution to another. Just like how you can take your code with ease from one solution to the next by cloning.
It’s the same idea that we already use for our code but applied to all the other bits that are necessary for maintaining projects.
There are some pretty obvious problems with actually implementing this, however. One of which comes down to getting all the existing code hosting solutions to agree on a standard. As they could simply create ancillary standards to differentiate thenselves. Not to mention all the work involved in implementing this when most people are accepting of what we have now (until it bites them somehow).
We've been building a platform called Skynet which makes this possible. It has a user-oriented data model: all of the application code is run client-side, and all of the data is stored under the user's control.
That means that someone can create a new application at any time which has access to all of the data - because all of the data is accessed client-side and owned by clients in the first place.
This doesn't solve the standards problem, but on the other hand I think what would likely happen is the first project to become successful would also become more or less the standard, with other people building extensions to that data standard over time.
I feel that there is a real need for permanent Storage with respect to Open Source.
Code breaks when old packages are unpublished or repositories deleted. Push once and fetch forever solves this.
Also Centralized solutions are providing open source collaboration tools for free, storage for free, because of their revenue from enterprise customers.
What happens when they decide to shut down? or change their policies? or just comply with wrongful takedown notices?
Would IPFS or DAT not suffice there? How is 'another permanent storage, that is a piece of a larger project, better than one that has the sole purpose and focus?
The challenge with IPFS and DAT is that you have no guarantees around the data reliability. The DHT style of p2p sharing pretty much only works for popular content. Incentivized storage networks can onboard any type of data and guarantee high uptime.
It's also been my experience that IPFS has significant performance issues. If you use a professional gateway like ipfs.io or cloudflare it runs at good speeds but as soon as you switch to being fully peer-to-peer it's almost unusable.
I don't have much experience with DAT, it may not have the same performance issues.
disclaimer: I work on an incentivized storage network called Skynet
Those are but some of the problems that IPFS, Dat (or Storj and probably Skynet too) do, or will face.
That doesn't make "rolling your own" any more reliable, performant, etc. So the question becomes even more apt: why will "building your own decentralised storage as requirement of a much larger project" work. If even the focused, dedicated "decentralised storage projects" cannot solve some problems?
With git it's rare for a project that's actually in use to go completely memory-holed, every contributor effectively having a local copy of the resource.
Using git (generally github) repositories for dependency management is, IMO, a hack and so it's not surprising that it often breaks. I like the way buildroot handles it (I'm sure they're not the only ones, but that's the one project I'm most familiar with):
- The buildroot buildbot fetches third party packages dependencies and archive them.
- When you build your buildroot image locally, it attempts to fetch from the third party directly. If the file doesn't exist anymore, it falls back onto the buildroot cache instead.
You could also easily add your own caching layer in there if you wanted too. I think that's distributed computing at its best: simple and robust, with a clear and easily understandable architecture. No blockchain-based proof-of-stake distributed storage, just a series of wget. And of course since everything is authenticated with a strong hash it's always perfectly safe.
Buy hard drives, do frequent backups, store redundant backups remotely, use RAID. At the end of the day someone must pay for the hard drives and they could just stop paying for it one day. There is no such thing as permanent and free.
> I need something more like email (independent, self-hosted servers with a well defined protocol to communicate between them)
The problem with email servers is you need a special type of sys admin to maintain them properly, they are not for the light at heart when used anywhere beyond the most trivial case. Any server that grows to some well-used size has a myriad of problems (getting outright blacklisted, etc).
Well, that's e-mail. Modern federated systems don't have a different server for sending and one for receiving. ActivyPub implementations are usually a single application with a database (like Pleroma) or a single app plus db/reddis/elasticsearch(optional) like Mastodon. Mastodon has official Docker containers, and it's not difficult to build one for Pleroma.
So you can make something "like e-mail" that isn't as bad as SMTP/IMAP/SPF/DKIM/etc... I've been considering hosting my own Gogs or Gitlab or one of the other locally hosted git platforms. I'd like to see something that allows pull/merge requests between them (you'd need some spam prevention of course; maybe require a message and a follow before people are allowed to push an request to your server).
This project ... doesn't seem like it does that at all. It's a desktop application .. with no real web view into your projects. I feel like it's missing a component, a service run in a docker container that you can program with your Device ID and push your public repos to for others to see.
I think that works - but what GP mentioned is where it fails:
> Frankly I would be perfectly fine with the current situation where you have a bunch of effectively centralized code hosting solutions (github, gitlab, bitbucket etc...) if you could trivially move your project from one to an other. For the code it's easy, git is built that way. For issues, PRs and the like it's trickier.
Maybe there's a nice way to Gitea distribute this information among Gitea instances, though it doesn't seem advertised as such - as this would basically make Gitea some neat Federated tool i think.
Ultimately i'd like Git[ea|whatever] to be just a frontend for a database that behaves like Git. In the way same way that Github's Source Viewing is just a frontend for Git. You don't worry about moving your Source data between Github and Gitlab, so why are we worrying about universal data like Bug tickets, Feature tracking, etc.
I'm a massive fan of systems that behave like Git and Scuttlebutt. Which is to say, they're dumb - simple. Git can be pushed and pulled from basically everything. There's no complex suite of nodes around the world that are expected or assumed to operate for any Git functionality. In the same way Scuttlebutt - which offers P2P layers, is similarly dumb (though less so, unfortunately) when compared to more complex P2P offerings like IPFS.
In my ideal world we'd have a database to pair with Git that would have some very basic schemas to complement Git. Possibly even baked into Git. Such that when you move from Github to Gitlab to Gitea - everything truly essential comes with. Some things might change, like your CI if it was bound to Github - but still. Losing some things vs losing everything.
I personally am less concerned about using Github/etc. Ie i'm not dying for someone to give me a new Github. I'm seeking a way to reduce lockin.
NOTE: I'm working on a distributed database that fits my needs on my above design goals. Really it's just Git + some additional data structures which allow for more data types being stored, such as binary and structured data to build foundations for SQL layers and etc. It's not intended for general use, but i'd love to see someone pick up the idea and run with it. "Git for Data" has been done a couple times, NomsDB and DoltDB namely, but they still felt like they weren't Git-like in that they wanted to centralize - probably for SaaS reasons.
Thank you for sharing your work and great to see more attempts on the same problem. I am one of the maintainers of the Radicle project.
The main problem we encountered with similar systems that rely on blockchains / dht for storage is the problem of 'blockchain poisoning'.
This is when someone deliberately adds illegal content to an append-only source in hopes to make the sole act of replicating the project legally problematic, as correctly pointed out by Konstantin Ryabitsev of the Linux foundation with regards to a previous version of Radicle that was relying on IPFS. see https://radicle.community/t/the-radicle-social-model/317
I think you could add moderation to a project like this much the same way you can add moderation to a centralized project. You don't need to be as heavy handed as "community voting", you could just have each client nominate a moderator who is able to append instructions to ignore content that the client would follow.
Under this model, every user (or project) can choose their own moderators, which means you don't have to worry about other parts of the community having different ideas for ideal moderation - each project/user can subscribe to the moderation feeds that they like, and ensure that they get a clean experience.
This type of moderation is actually an upgrade from centralized systems, because it is much easier to nominate new moderators if you don't like what the old moderators are doing.
Considering the illegal content is added by someone who has access to the repository. The right way to address that would be via community voting, which then can decide to hide it from the platform since the data is permanent on Arweave.
This governance workflow will enable the community to make such content policies.
This kind of thing always makes me sweat. Are deletes at all possible? What if someone accidentally pushes keys to the repo? On regular github, at least you can nuke the whole repo and start over if need be.
I don't know. You can always clean the Git history & force-push it, but the developers would have to explain if there's any backups or archive kept anywhere...
Since data is stored permanently on Arweave, there's no way to remove it from the blockchain. However, you could force push your repo which would remove your concerned commit from Gitopia repository view.
My first reaction when I read "peer-to-peer" in the title was "cool" followed immediately with "oh it's going to push some cryptocurrency crap, isn't it?"
But honestly after reading the page it look fine to me. Oddly enough they seem to use cryptocurrencies as... currency. They don't bullshit you by saying that you're going to store your code on the blockchain.
Besides, while I long ago became tired of the cryptocurrency crowd reinventing squared wheels every other month, the problem of rewarding open source developers is still very much an open issue, so I'm willing to give it a chance, even if I'm not holding my breath.
This seems like a cool project frankly, at least on paper, I don't think it's fair to discard it just because it bundles some optional Ethereum support.
Actually after downloading the upstream client my only complaint so far is that it's yet an other bloated Electron app, but such is life in 2020...
Also I actually think it could be used pretty effectively - not saying it does this today or would ever - but it could let you offer a bounty for 'whoever submits a PR that closes this issue; that the maintainer accepts; that is not reverted within 30 days' in a trusted but decentralised way.
Because the cryptocurrency hype funds/funded most of those projects and/or the prospect of adding a cryptocurrency to the projects causes VCs to fund those projects.
In this particular case Radicle came out of OScoin (or is the new incarnation of it?) and was funded by BlueYard.
Ethereum (and blockchain tech in general) genuinely open new doors to development and make it possible to do things that were not possible before. Especially now that we're several years further along, the tooling is a lot better and the design space is significantly more thoroughly explored.
Yes, there's a lot of shady activity, a lot of scams, a lot of broken technology, and a lot of people with visions they can't deliver upon, but the same was true in the early days of the Internet and blockchain is starting to move past the 'dotcom bubble' phase and onto 'this tech is actually useful' phase.
It's not there yet, most of the tech is still nascent, but it's a lot less nascent than it was in 2017, and there are more people working on it than ever.
Without an external entity assisting with proof-of-stake like Kraken, etc., Bitcoin (the system) is dependent on not just peers connecting to each other to have merry time with financial transactions, but on something called proof-of-work (https://www.kraken.com/en-us/learn/proof-of-work-vs-proof-of...).
That proof-of-work in the Bitcoin system itself (without use of an external entity to handle proof-of-stake) is today largely handled by workhorses like those getting cheap electricity from thermal vents in Iceland (https://www.wired.com/story/iceland-bitcoin-mining-gallery/) verifying more and more transactions for less and less benefit. They're reliant on Moore's law and cheaper and cheaper energy, with more and more trust overhead processing by validating transactions, which doesn't necessarily scale, creating a need for proof-of-stake entities to substitute.
Etherium (the system) contains within it proof of stake, but external entities (e.g. Kraken, etc.) can still validate proof of stake, if desired. Personally, I'm unsure if Etherium's proof of stake on its own is enough, because I think blockchain can be compromised (https://www.technologyreview.com/2019/02/19/239592/once-hail...).
So, that's essentially why they choose Etherium (proof of stake).
Global equity and inequity revolves around those that essentially "hold" the value (proof of stake), and banks hold the money in our current financial system, largely based on USD (https://www.investopedia.com/articles/forex/11/popular-curre...). Large banks have the ability to basically "re-use" debt multiple times, creating debt from debt (via Fractional Reserve Banking) as well as other means (https://www.investopedia.com/articles/investing/081415/under...). Wherever you are and whatever chaste you're in, if you can sell your potential for paying a bank back, they can create money out of debt for you. Yes, this devalues the currency, but if you do well with it, you come out on top, you give back in interest, and the overall value is greater than the inflation of the currency, and outsiders investing in those companies can be important. If investment, etc. fails or the market fails, that system fails. Otherwise, it kind of works ok.
The proof-of-stake entities will hopefully continue to generate value similar from nothing/debt to help those that can help others until this world is done and we move on.
I've installed the "upstream" client but I must say that I'm a bit confused. I imported a couple of git repositories that ended up on http://seedling.radicle.xyz/, so I thought I did it right, but then if I try to add projects from that very page it keeps searching and never finds anything (they're stuck in "keep looking" mode).
Also I don't see how you can create issues. Is it not implemented yet?
It's an interesting project but it feels like very early alpha-grade to me. The client gives very little feedback on what's happening and what you can do.
This is really helpful feedback. Especially the part about not getting enough feedback during operations. And yes social features like issues and PRs have not been the focus in this release, as we focused on replication. If you are looking for more help you can join the community matrix and we take it from there: https://docs.radicle.xyz/docs/using-radicle/join-the-communi...
Thanks for the feedback on my feedback. My recommendation would be to make a very simple tutorial (maybe even a video) walking the user through checkouting a remote project, publishing their own and start hacking while explaining the core concepts. The docs are pretty good from what I see, but when you're just starting and you don't know what you're looking for it's a bit overwhelming I thought.
It seems that it is sadly only built for AppImage and MacOS neither of work on any of my current machines. Though I guess it just means that I have to figure out how to build it myself.
Awesome project, though the perpetuation of open source software needing to be free is regrettable.
> Software as it should be.
> Free forever
Mostly all popular projects need some form of funding, and setting the expectaction of a free lunch forever for new users is not healthy. Btw, do you remember who used the tagline "It's free and always will be"? It was Facebook.
Important to note that "Free" here doesn't refer to "for free". You rpoint about funding of popular projects was at the heart of radicle from the beginning. We believe that FOSS as backbone of the digital infrastructure needs to be sustainable, which includes the resources/funds to maintain it and keep it free and open. If you wanna find out more about the philosophy we follow, here is the original research and premise: http://oscoin.io/
I've been back and forth with members of the open source community a few times on this, and it seems like a battle that isn't going to be won. Software that has a price tag attached to it is unlikely to be accepted as open source, from what I can tell.
Which makes me wonder: should we come up with a new name/classification for software that is 'free as in freedom' but not 'free as in beer'?
I don't know what 'free' means for the project, but open source and 'free as in freedom' are not redundant these days. While open source is legally indistinguishable from free software, time has proven that open source software can be designed in non-free ways. Examples:
- Bloating codebase so much that it can't be audited, extended or forked easily
- Tightly controlling the development
- Open shims for opaque blobs
- Hiding documentation and troubleshooting information
Free is a term used by the community for decades, literally in the name of the Free Software Foundation. I guess you could argue that their need to explain what free means indicates it was a bad choice to use, but it is pretty standard now.
It's weird to think P2P is becoming all the craze for "privacy" while it's the backbone of the internet: it is p2p. It's just nowadays its more of P2(big cloud servers)2p; which could be a good thing depending on who you ask and your usecases.
I always thought maintaining servers was silly since BitTorrent already proved we can achieve higher bandwidth throughput using lots of clients communicating together.
But p2p is more about the network connectivity than whether the node is an Amazon server or a mobile phone. The normal Web for instance does not build on this network nodes capabilities. We need more apps that build these kind of collaborative and self-sustainable networks
I mean it works in the use-case where you have a single file version everyone is hosting, but it gets a lot more complicated when you’re talking about dynamic content doesn’t it? For instance how would you synchronize all the content on a hacker news thread between all the clients?
More like the latter. The first funding feature we are launching will allow you to set a monthly budget and have it split amongst a set of users/maintainers of your choosing.
peer-to-peer is beautiful concept but note that git is already distributed VCS. you can have many remotes and mirrors. Just that p2p is not necessary here in git and using Radicle doesn't free my Code.
It has an issue tracker, pull request manager, manages releases and users,... All this cannot be replicated with a simple "git clone".
What Radicle seems to do is to offer some sort of social network on top of git. The novelty here is not the decentralized nature of git, in fact it is what radicle relies on to make its social network decentralized.
So you need 3 accounts on 3 different services to achieve what radicle does.
OK, let's say you use your Github account for all of them instead, now you have centralized your accounts and if you're another youtube-dl, Popcorn-Time or just happen to be unlucky enough have the nationality of a country that the USA likes to hate against, that account is gone.
As for updating all those mirrors, how do you do that? `git push --all` ? `git push --mirror` ? Is git configured to so automatically? Or are you going to configure push hooks on one of those services?
What about your issue/ticket and PR/MR management? Where will that be? Are you going to use an in-git solution like https://github.com/MichaelMure/git-bug, somehow sync everything using custom scripts or wait for https://forgefed.peers.community/ to be finalized and implemented by all code hosts?
How are you going to collaborate with others?
How are you going to introduce newcomers to all these options?
Do you know of a tool that solves most (or all) of those issues?
Actually, it's not fault of git. Workflow of git takes place through email and patches.
But,github wanted to make this process easier for the people,hence they included issues,fork and PR model. It was easily done with intuitive interface without necessity of email for workflow, but if you have asked me, i would have issues,wiki,etc. integrated within repo just like Fossil VCS.
p2p is cool but not solution to this . gitea/gitlab/etc. already provide importing of issues with repos and if not,they must provide that feature.
> Actually, it's not fault of git. Workflow of git takes place through email and patches.
This invokes the "it's not a bug, it's a feature" mechanism. E.g. Fossil has no problem integrating issues, merge requests, and wiki pages inside its repositories.
Yes, but that's a problem for the users which GitHub has every incentive to never solve. It is a problem of github and projects like radicle are a solution.
Looks cool, but the p2p protocol seems over engineered. The problem is not so much how to share the code, you can still use email or some other centralized federated service to communicate with peers. Hell, you can even use S3 to store your backups and EC2 to run CI. The main issue is owning the platform that hosts your code, issues, and other artifacts. A hybrid system that allows you to host code with peers while integrating with existing infrastructure services would be more robust and an easier sell.
I specifically want to work on git projects, including the project management aspects, without having to deal with running my own server. The p2p protocol is not over engineered, it's exactly what's needed. Git is p2p. Why shouldn't it have p2p pm tools?
i think this is technically interesting, but i'm curious in practice what it gives project maintainers over hosting their own gitlab instance or similar...
Good question. I know of a few projects hosting their own GitLab instance, the problem is that this requires me to create a new account/identity for each of these instances. This is a far cry from what GitHub brought, which was a single "place" and social network where you could browse and contribute to all projects with the same account.
Radicle attempts to take back control (just like running your own instance), but without giving up network effects.
I've got a number of tiny projects. Realistically if they're not hosted on GitHub, they won't get contributions. "Setup another login on my gitlab instance" would close to ensure nobody collaborates on it. This allows me to both disconnect them from a centralised service and remove the "you need a separate identity" step.
Oh come on. It's not like making an account is overly difficult or demanding. You are not required to send two forms of ID or a blood sample by mail.
Anyone who really wants to contribute to the project (and scratch their itch) will not have a problem with entering a username, password, and perhaps use a validation link from an e-mail. It might discourage people with just fleeting interest.
And as a hypothetical FOSS project maintainer, I know I'd rather have one of the first kind of contributor than ten of the second kind. Especially if the alternative is to be beholden to the likes of Microsoft.
Of course, the best solution would be something like ForgeFed, but I can't see that meaningfully taking off (there's no way Github will ever adopt it). I'd love to be wrong, though.
The step is not difficult. The step exists and that's enough. Search through HN comments and see how many people see creating a new account as annoying.
And I understand it - If I have a one line fix but the relevant system requires a new account, I don't bother. If it's a significant fix, but the project requires extra signed document (CLA?), they're getting a description in an issue instead.
There's a reason for a recent trend where new services let you jump right in and start using them. Then require amount creation only when you do something significant.
And for a small project that potential drive-by fix is valuable. It's not like I get to throw away most people to select the best ones. I get one potential fix a year - either it's a seamless experience or they disappear.
Somebody still needs to agree to hosting your data. Incentivizing peers to host your encrypted data is not a solved problem. IPFS is trying to bootstrap some cryptocurrency to fix that but they seems to be taking their sweet time with that.
So, ultimately, you always end up with somebody providing the convenience of not throwing your data away for a fee. Github and Gitlab seem to be the popular options for that. Gitlab is actually open source and you can self host it if you want and many do. But the reason they have a nice valuation is that they have lots of customers that prefer them to do it.
Given that it's MIT Licensed, you can even do that and offer it as a service probably (Amazon, there's a nice idea for you :-) ).
> IPFS is trying to bootstrap some cryptocurrency to fix that but they seems to be taking their sweet time with that
AFAIK, Filecoin is live now, and seems you can use it now for getting peers to host your IPFS data.
But, I'm also unsure that incentivizing peers with actual money is the best and/or only solution. BitTorrent works today for free, many peers are seeding content just to be seeders. DC++ worked yesterday, where people shared data just to share data.
While probably offering money for storing data will get more people onboard to store others data, it doesn't seem to be the only solution we have at hand to get free sharing of data.
> Social collaboration features (i.e. bug reports, patches, discussions etc...) are all on the Radicle roadmap. They will work very similarly to the experiences we have now, but will be local-first and cryptographically signed. This means issues, PRs, and discussions will be more secure, available offline, and stored on your machine as git objects — not on a central server!
I spent a lot of time watching the GIFs on repeat rather than reading the text on the web page. It is quirky, I like the style, but it is a distraction from the message.
Look into how the Linux Kernel and other projects do development. I think a larger issue is why do we need a platform like GitHub when SCM can be done through email?
Or just use Fossil. It's already a distributed alternative to github. Every fossil install includes a built in web server with bug tracking and a wiki.
To add to that: there are several major stablecoins on Ethereum: USDT, which is backed by BitFinex and has $12 billion in circulation, USDC from Coinbase/Circle with $3 billion in circulation, GUSD, from Gemini, BUSD from Binance with $700M in circulation, and DAI, which is decentralized and has $1 billion in circulation.
These are all ERC20 tokens so easy to integrate into Radicle, and offer a way to allow developers to get paid peer-to-peer while completely avoiding the price volatility of typical cryptocurrencies.
There are so many issues with email that I'm not even sure where to start, and they've been repeated many times in previous HN threads anyway. Suffice to say that clearly it doesn't work for a lot of people, because otherwise we'd all be using it.
I know about git-send-email. But you still need some kind of website for project info and code (unless you only wanna give out your code on request via email) and a patch/bug tracker if you want your project to be approachable. Larger projects and business users might also want CI.
At first glance the desktop client GUI looks really nice and easy to use, which I think is pretty important to get right.
Unfortunately it loses a lot of convenience by not having some kind of web interface, even if it's only for discovery. One way for something like this to spread is by sharing project URLs that anyone can open in a web browser.
I don't understand peer to peer. Is every fork on everyone's computer? Who holds the latest source of truth? How does a client know if they are up to date if everyone else around the client is behind?
Is there a good resource for learning p2p and how the protocol works around establishing who owns the most up to date data?
I'd love to see just one (1) sentence on their home page that describes what Radicle is and does. I searched for the simple description by scrolling across the entire web page, from top to bottom, and did not see anything like it. There were all sorts of hints that it could be interesting, but c'mon.
Privacy by necessity will use end-to-end encryption, as artifacts will end up being propagated on the network. This isn't however so easy for long-lived artifacts (eg. what happens if your key is compromised sometime in the future), and we will need things such as forward secrecy.
It's not 1989 anymore, we have proper cryptosystems now. I don't have a worked example but elsewhere in the thread someone, it sounded like a dev, mentioned it's being worked on. You can encrypt for certain public keys and then only those people can decrypt the contents.
For any given P2P system which can be used to share a large amount of files, we can prove the system cannot exist with this question: Is there a way to prevent classified documents of the US stolen by China, or child pornography from being shared using the system?
If the answer is yes: I'm afraid to tell you that the system is not peer-to-peer in the sense that there is a central authority to censor what content is to be shared. Therefore projects like youtube-dl can be easily erased.
If the answer is no: Such a system with no possibility of censorship is too dangerous. What if there is literally no way to prevent information that threatens the security of the US from being shared? Fortunately as of now, no such a system exists on the planet. Maybe you now have a vague idea why such a system does not exist.
Is it possible to self host this and isolate it on your own p2p network? Would be really cool to handle the decentralized part on my own computers without needing to hook into the global p2p.
That's absolutely possible. Everyone is empowered and encouraged to run their own seed nodes. Which would allow you to have an isolated network. Check the docs to find out how to run your own: https://docs.radicle.xyz/docs/using-radicle/running-a-seed-n...
Would you consider linking a white paper off the homepage? (If there is one, I'm not finding it). I like the sound of this project but I really would like to understand it more fully.
at the end of the LPC2019 talk "Reflections on kernel development process, quality and testing" by Dmitry Vyukov there's a slide with some Radicle examples. The following slide he links to a post by Konstantin Ryabitsev "Patches carved into developer sigchains" that shows Securescuttlebut on IPFS as an alternative to Email as decentralized system (search for git-ssb).
Just kicking the tires. The beta was released just a couple of days ago. The very basic features seem to work just fine, and the rest is an obvious WIP.
The team behind it seems super responsive and engaged.
The design of GitHub means that your canonical upstream is only accessible through the internet, and so are your issues, PRs etc. If you're offline, you can't access it, and if GitHub is down, same story.
Radicle, on the other hand, keeps all of this replicated locally, so push/pull works offline, and the code/social artifacts are replicated asynchronously, when you are online, but you don't need to be online to work with your project(s).
GitHub has a pretty extensive API; it's not hard to write a simple script to clone all that data if you want to, or publish it somewhere else. I'd be surprised if there aren't already a dozen of those scripts floating around already.
Why not? You can create issues with the GitHub API (and the CLI); it's not hard to imagine a tool which would "sync" issues from a local database or some such. The reason it doesn't exist is probably because there's not a lot of demand for it.
Come to think of it, it wouldn't even be that difficult to sync this database to someone else, too. Although to be honest this doesn't seem all that useful to me.
How does push/pull work off line? That sounds impossible. Just scheduling a push doesn’t actually push anything. That’s like commuting to my local GitHub repo and having a scheduled push/pull every 10 minutes then?
The reason you can push/pull works offline is that the database of radicle lives on your machine. Once you are online it will gossip with other peers to exchange updates of projects. This means that your workflow stays the same no matter connectivity and eventual the network convergences to communicate all relevant data. If you are interested in the details check out the docs: https://docs.radicle.xyz/docs/understanding-radicle/why-radi...
No, the full feature-set is available offline. You can browse your repos and any other repo you replicated, and push/pull. What offline means is simply that your changes won't immediately be replicated to peers. But the full app experience (Read and write) works offline.
You can't push within LAN and then have that automatically available when online to the wider network, unless you have some form of continuous replication to some public-facing host. This is what Radicle does for you.
This doesn't look like "alternative to GitHub" to me; you don't need to download any client to use GitHub and having a nice web interface is one of the most defining feature of GitHub.
GitHub is a “social coding” platform that provides collaboration features (access control, issues, etc) on top of Git.
This is a social coding tool that provides collaboration features on top of Git.
It provides a desktop app because it’s peer to peer. That’s an advantage over a web UI for developers looking to avoid a dependency on a centralised third party.
You are free to continue to play in walled gardens but this is very much an alternative to that.
GitHub's primary value add to the world isn't that it's a web interface to git. It's also a social network, an issue tracker, a workflow management system, a code review tool, a wiki-builder, a frontend for your CI, and plenty more.
If github disappears tomorrow, all the code will be safe and decentralized already, yes, but most of the workflow of the software world would be significantly stunted for a good while, because everyone would need to migrate to something else (like GitLab) and then take the time to rebuild all of the data and flow that is on Github but isn't captured within the actual git repository.
This comment is spot on, people who jump to the conversation with the argument that Git is already decentralised don't understand where the most value is captured when it comes to collaboration. It's the social artifact, issues, PRs, etc. And the cost of migrating the community of a project/organisation and their social artifacts is a massive cost, carrying the risk of splitting the community and or stifling any other progress to stay relevant.
Yeah, we will eventually move to L2 if it is able to deliver what L1 does at a cheaper cost. Currently this isn’t the case, as only token transfers are possible on L2.
Now, the downside of this mvp is that there is no project discovery in the client itself. We need to go search for projects in a browser, in this page http://seedling.radicle.xyz/ which is a bit confusing. Considering the client itself is electron, it could at least, open this page for us somewhere. Or, we could at least have a less "noisy" seedling page focused on search and I would not even know it wasn't part of the client itself.
Overall, awesome project. I really hope it will grow and add the missing essential features. If I could vote, with priority these would be:
- project discovery integrated in the client - issues support - pr support - multiple identities
Anyway, great job!