Maybe I am old fashioned or stupid.. But should our software not compile from local resources only?
For me it is the only way to keep a kind of control. Download and then compile.
Not old-fashioned or stupid in the least. The question here is precisely how to ensure the availability of the source code, and who should bear the costs of keeping it available.
Download from where? Whoās paying for that download infrastructure?
8 Likes
Hmm, how long does it normally take for a node to pick these things up?
My understanding - main reason for this discussion - problem of forking zig repo on codeberg
May be we can think about two repos:
- Main - for core team (current repo)
- Contributors
Instead of working on forked repo, we can work on branches
Need to provide way of
- signing some agreement for contribution
- branch creation for contributor with protection rules (if possible)
- sync between repos
- etc
And we can ask assistance of Codeberg team
1 Like
That doesnāt change anything regarding codebergās uptime/availability.
The seeds acting as mirrors of the repo and therefore providing availability is I think the core reason for kristoffās (and mine) interest in radicle.
4 Likes
looks like admission of inability to support large projects
Here you can see me submit an issue, the monent I save the file and close the editor you can see the radicle client synchronizing with 3 hosts almost istantly. Since one of those nodes is guaranteed to be my own (Iāve configured it as a preferred node to connect to), the issue becomes available from the web UI instantly as well.
https://www.twitch.tv/videos/2845060014?t=02h26m56s (timestamp)
2 Likes
Iām a bit confused by whether that link is supposed to support what youāre saying or not. On the one hand, itās Marlinspikeās talk on the benefits of centralized systems. But itās accompanied by a 5000 word critique taking apart the flaws in what he was saying, including a defense of specifically the bittorrent protocol, among others?
Either way, it was an interesting read.
Edit: a quote towards the end is a nice tl;dr:
To me, the talk at the 36C3 appeared to be more of a sales pitch for capitalism-driven, centralized platforms than a well thought out and honest talk about decentralized systems.
1 Like
After thinking more about it, I think radicle has potential for quite a few projects, but not for every project since some need an end user (as in mostly tech illiterate) facing issue tracker too.
Do you mean write access issue tracker (you can already read some information on web UI)? Yeah, you need a node and identity to create issues, maybe someday it will be possible in WASM.
Thatās because I mindlessly used the first link I found about Moxieās talk :D. In retrospect, it didnāt apply well to my argument anyway. My point was narrowly about decentralized p2p, whereas Moxie was arguing that all standardized protocols reach a point of stasis. IMO decentralized p2p works for use cases that demand censorship resistance and arenāt latency sensitive (BitTorrent) but beyond that, the added complexity doesnāt pay off.
1 Like
Yes, I mean creating and commenting on issues.
I think itās impractical to make users setup a radicle node if a reasonably large chunk of them already struggle with picking the correct file type in a āSave Asā drop down.
Obviously it depends on the software in question how many of these users exist.
3 Likes
If your users are complete novices, there is also the option of building a report feedback form directly into your application and have it send the report to a self-build/hosted issue tracker via some api. At least for some apps that would work.
(And you could either have that use decentralized or a centralized system based on what you want to support for that (basically it could be a freenet private river-chat-room between the user and developer built into your application))
Also I think if you push the user knowledge/familiarity-level towards zero you can always argue against any kind of newish solution.
2 Likes
But does this apply to radicle too? I donāt think every p2p system works the same way, they can optimize for different things, I think it would be better to do some practice runs and see how it works in practice.
For example radicle uses the gossip protocol (which should have relatively low latency) which is used to push reference announcements (basically subscription/push notifications) to inform people who are interested about a particular repo about updates to it.
Also with bittorrent there are so many different clients with special features and implementations (just from looking at wikipedia), that it seems difficult to talk about in general terms, I also donāt know how relevant it is to begin with, because I doubt that we can generalize the performance metrics from one p2p implementation to all of them, especially if they use different algorithms.
Additionally I think that with people wanting to get informed about code repositories and keep them up to date, you have a different starting position for designing a p2p system, then with people wanting to download some never changing blob one time, for the latter it is clear that update latency doesnāt matter so why would the system be designed to handle it well.
I think having no single point of failure is a pretty big benefit, especially if the latency for updates is still below a few seconds and @kristoff described it as almost instantly. (Which matches what I would have expected from the use of gossip protocol)
Having a open participation model where everyone can chose to add additional redundant hosting for everything they want to provide is also pretty neat, because that means that people are just free to do the things that serve their own interests and then they also can choose how much they additionally want to help others with additional seeding.
With centralized systems there also can be the situations where you just happen to have a terrible connection to any centralized replica near you, with a p2p system like this you can fix it yourself by hosting a seeding node that is near to your location, with a centralized system you can just complain and watch while barely never anybody does something about it.
So I think you are overstating the benefits of centralized systems, while understating the benefits of decentralized systems by comparing them unfavorably to bittorrent (which has different goals and way to many implementations to have a meaningful discussion that is rooted in some algorithmically precise notions about what some specific implementation is able to achieve).
Is centralized easier and faster in ideal situations? Sure, but that still doesnāt mean that it is worth the cost of having that centralized point of failure and no independent leverage over what kind of quality you get. It also makes it impossible for people to benefit from each others generosity and collaboration on sharing hosting resources.
5 Likes
No fancy protocol is going to fully compensate for the inherent chaos of a network with open node membership. Nodes are joining and leaving all the time, often on home internet connections and running with a wide variety of software stacks. You can claw your way back to availability with redundancy and retries, but then you lose in latency. Thereās no getting around that.
You can achieve āhaving no single point of failureā without decentralized p2p. As long as the issues and other metadata are stored inside the repo, you can easily push to multiple servers. The only reason Github is a single point of failure is because that metadata is stored in their proprietary database and canāt easily be moved or viewed offline.
2 Likes
The way I think about Radicle for my day-to-day is essentially as having my always-on node (radicle.kristoff.it) as my self-hosted forge. I have it configured as a preferred host and whenever I push, the announcement goes there first.
Currently my Radicle client is configured to try to seed my changes to 3 hosts before the command returns, so Iām currently also leveraging iris.radicle.network and probably some other node that other people have setup to seed Zine but, if nobody else wanted to seed Zine, I wouldnāt mind and I would just configure my local client to require only 1 successful copy instead of 3.
This workflow is essentially the same as one with a traditional forge, but then after the initial push, other nodes can get a copy of my changes, if they want them, and Zine becomes more resilient asynchronously from my normal workflow.
5 Likes
I wonder what the storage usage is like if you have years of issues, patches, and discussions in your repoā¦ Currently my Codeberg Storage Overview page says Iām using about 800MB, presumably just counting source codeā¦
Also, can issues have screenshots or other files attached?
2 Likes
@xeubie Iām looking forward to trying out your vision of source forge too. I think your best argument is just making something great and letting it speak for itself.
Friendly competition is good. Iād encourage you to try Radicle in earnest and see if it has any inspiration to offer, as well as considering how you can lean even more into the particular niche that youāre exploring with haxy.
4 Likes
Forgejo is also working on their own version of federation based on Activitypub.
https://codeberg.org/forgejo/forgejo/issues/59
This is clearly an area of interest for a lot of people. Radicle looks great in that it actually works now.
1 Like