At the moment there is no Etherum integration at all. Down the road we are going to add entirely optional ways to benefit from the extra security, authenticity and coordination tooling backed by something like Etherum. All the code collaboration functionality will be unaffected by it and and at no point are users expected or required to use the optional features.
Thank you for specifying that, that is exactly how I understood it and while I appreciate the optional integration, there is one planned and that for me makes this project very unattractive. Which I think is a shame, because the P2P aspect (alongside it being open-source, written in rust, having a very polished presentation) of it looks very good.
Great to hear that the messaging on the website makes that clear. Out of curiosity what are the reasons for the strict rejection based on that optional feature set?
I reject any blockchain-related project, because blockchain is wasting a huge amount of resources for absolutely no gain. Associating a project with it - even by making it optional - means you support the ideas behind blockchain, so I automatically can’t support the project.
Proof of Stake, proof of work, mainnet = production. Stage zero - this new production network does create new blocks and mints validator rewards, but it is yet to be upgraded to network that can do proper transactions. Also, question of turning off PoW of Ethereum 1.0 is still not very clear. First two networks need to be merged into one.
They are making steps (just launched a first of series of network upgrades) on a road that will lead to PoW being fully replaced by PoS in Ethereum. So - yes. But it will take some time.
Please note that the costs of PoW are distributed onto every holder of cryptocurrency. And some of that cost is distributed on everyone else in a form CO2 emissions. They are offsetted by of carbon tax, but only in some of the countries where miners operate.
Everyone is interested in PoW becoming a thing of the past.
To me, “proof of work” feels a little like the internal combustion engine. It’s kind of dirty, and grew so big in our time that it needs huge amounts of power to continue to work (as in drilling for oil and fracking all the things to make cars go brrrr): it’s “what we have” (or “they” have, whatever) because for a while, every blockchain based cryptocurrency went for it.
Now, some people are not completely oblivious to how stupid this looks, and alternatives are slowly coming around (proof-of-stake for eth, consensus protocols for xlm, etc.). The future is looking brighter, but as for BTC it’s just too late: it’s expensive because it requires huge amounts of investments to exist and allow transactions.
Blockchain hype is pretty large source of free software funding that doesn’t corrupt the movement to serve a couple of oligarchs. Both offer freedom.
I am not fan of blockchain snake oil peddlers myself, but if they manage to convince a bunch of greedy, rich capitalists to lose some money on free software alternatives to the status quo, I am content.
Public smart contracts also incentivize research of formal methods, dependent typing and other methods to improve software correctness. Another great win.
blockchain is wasting a huge amount of resources for absolutely no gain
As mentioned down-thread I think you mean “proof of work” and not “blockchain” here. Git repos use a merkle-tree block-chain just like Bitcoin, for example, and there’s no proof of work there.
I also think it’s ilkely you misunderstand the nature of “wasted resources” in a proof of work algorithm (blockchain related, or otherwise) but that’s a side issue here.
This stance comes from a place of ignorance on how energy is generated and converted into proof-of-work. It’s a shame because blockchains are here to stay and will only grow in consumption. The majority of electricity in use by proof-of-work chains today comes from excess hydro energy. This is energy that was already harvested and would go to waste if it wasn’t used to secure bitcoin. There are today several large projects looking to do the same: make use of excess energy harvested by power plants, and turn them into money. There is really no need to create new energy to power cryptocurrencies. That, I agree is a waste, and completely unnecessary.
Whoa, wait a minute. That’s like how I can buy the meat in the supermarket without being responsible for animals being slaughtered because the animals have already been slaughtered anyway, right? There’s no market involved here or anything.
There is really no need to create new energy to power cryptocurrencies. That, I agree is a waste, and completely unnecessary.
I know this rationale very well and I think truth is somewhere in the middle. Yes, mining is clearly a way to turn that excessive (in off-peak hours) energy into useful work. BUT! ATM any other, potentially more useful way of turning this energy into useful work needs to compete with miners. Potentially, that energy could create aluminum, fill water tanks, charge huge batteries, etc.
Also, the way demand supply/demand for hashing power works - in times of high prices of BTC (like now) people are likely to run miners everywhere, not just next to large power stations in off-peak hours.
the website has been remade and the old articles are gone. Is this some kind of relaunch? Are the people behind the old radicle still around?
Funnily enough, the article makes no mention of blockchain, while the community discourse shows that monadic.xyz appears to be funding radicle development and is looking for blockchain developers to work on it. This still seems to be tied to oscoin.io, quite curious where the money for this keeps coming from.
It’s less of relaunch and more of an update on our development. After launching last year, we learned a lot from early users and iterated on our design to focus the direction of the project. We’ve been communicating these changes as we process them (see here and here) — this post is simply an attempt to present those changes and realign the public direction of the project. The website has been redesign to reflect these changes. All previous work on the project still exists in the old repo.
Monadic does indeed fund development on the Radicle project and did fund the oscoin.io project. oscoin has been sunsetted as a “product” and the research that went into it will instead be implemented within the Radicle project (see new website). The article does indeed (second to last paragraph) mention this approach with the presentation of the global registry that holds canonical project metadata. On “where the money comes from”: Monadic is funded by the partners presented on the website and Radicle is — and will remain — a free and open source project.
Hope this provides more clarity! More frequent updates on development will be shared on the community discourse.
It has been considered piggybacking on email for the distribution of patches at least. It falls short when it comes to questions of code hosting, public visibility and generally encoding primitives of code collaboration (open/close state of issues, same for patches/pr). Where it could be leveraged in the future is for notifications of updates to projects one follows.
The Radicle IPFS daemon is the process that runs an IPFS daemon, bootstrapping to our own separate Radicle IPFS network.
I know next to nothing about IPFS so this is a genuine question: why is the Radicle network separate from the main IPFS network? Does this mean that if I want to use both IPFS and Radicle then I need two daemons?
For you second question: yes - they run independently of each other.
They are separated as we don’t replicate general files, you can’t really make use of them without being in the context of radicle. A better way is to think of ipfs as the technology we picked for replication and not the ipfs network which one partakes when starting the default ipfs daemon.
The main reason is that currently IPNS name resolutions take a much longer time in a larger network. It seems like we’ll soon have fixes for that, so in theory we could move back to using the main network.
We use both - IPFS for storing the data, and IPNS to point to the head of the list/log of expressions to a machine. Thus, when you update a machine (e.g., add a new issue), you’re adding an item to IPFS that has the new data plus a pointer to the old data, and updating the IPNS to point to that. When someone reads, they resolve the IPNS, and then read the corresponding data.
In theory we could implement such a pointer system ourselves, or use something other than IPNS. But it seems like improvements to IPNS are happening faster than we could come up with an alternative, so we settled on IPNS.
Ah, so you’re using a separate IPFS network because the normal one is too big for IPNS now, and yours is still at an early stage, thus small enough that IPNS is fast enough? If yes, then please do move to normal IPFS as soon as you find that the improvements make it feasible. And, for the sake of future generations, please don’t use an “It’s too late” argument to avoid such a move. It won’t be.
I’ve only skimmed the site, but what it appears to be missing is a way for users to submit issues. That’s one of the major things (other than discoverability) that Github adds over git itself.
Not specifically, but everything I’ve seen appears to require to you to install radicle and then use the command line. I have an OSS project on github with a couple of thousand users, many of whom aren’t particularly technical. One the main benefits I get from github is that my users can report bugs or request features very simply.
Oh! I really like this.
I just did the tutorial and I had a problem when running rad project init.
It exits with
fatal: unable to find remote helper for 'ipfs'
Error: git -u origin master failed.
Apart from this, is there any easy way to apply a patch locally without accepting it to test changes? Because I guess once you’ve accepted it that is already merged for everyone.
With that you should be able to accept the patch locally in a fresh checkout of the project somewhere else on your filesystem, this way exercissing the process of proposing of accepting entirely locally.
I installed it from source using stack. I don’t know right now, not home. Will check later when I arrive and get back to you. I’m installing it right now at the work computer to see if I have the same problem also.
Very interesting, in a way I’m curious about how this will evolve, but the Ethereum integration is a huge turn-off.
At the moment there is no Etherum integration at all. Down the road we are going to add entirely optional ways to benefit from the extra security, authenticity and coordination tooling backed by something like Etherum. All the code collaboration functionality will be unaffected by it and and at no point are users expected or required to use the optional features.
Thank you for specifying that, that is exactly how I understood it and while I appreciate the optional integration, there is one planned and that for me makes this project very unattractive. Which I think is a shame, because the P2P aspect (alongside it being open-source, written in rust, having a very polished presentation) of it looks very good.
Great to hear that the messaging on the website makes that clear. Out of curiosity what are the reasons for the strict rejection based on that optional feature set?
I reject any blockchain-related project, because blockchain is wasting a huge amount of resources for absolutely no gain. Associating a project with it - even by making it optional - means you support the ideas behind blockchain, so I automatically can’t support the project.
Ethereum is starting it’s PoS transition, stage zero, mainnet literally today, first of December. They are working hard to drop PoW.
EDIT: Here is a launch event live stream: https://www.youtube.com/watch?v=MD3mADL33wk
EDIT2: Eth 2.0 beacon chain explorer: https://beaconcha.in/
I have no idea what “Pos”, “stage zero”, “mainnet” means. I assume PoW doesn’t mean prisoner of war, but proof of work?
Proof of Stake, proof of work, mainnet = production. Stage zero - this new production network does create new blocks and mints validator rewards, but it is yet to be upgraded to network that can do proper transactions. Also, question of turning off PoW of Ethereum 1.0 is still not very clear. First two networks need to be merged into one.
So regarding my argument that
you are saying that they are taking care of the amount of resources consumed by lowering the energy consumption?
They are making steps (just launched a first of series of network upgrades) on a road that will lead to PoW being fully replaced by PoS in Ethereum. So - yes. But it will take some time.
Please note that the costs of PoW are distributed onto every holder of cryptocurrency. And some of that cost is distributed on everyone else in a form CO2 emissions. They are offsetted by of carbon tax, but only in some of the countries where miners operate.
Everyone is interested in PoW becoming a thing of the past.
At least that’s the long-term plan for Ethereum.
Bitcoin, for example, has no plans to move towards Proof of Stake. Neither do most other blockchain based cryptocurrencies.
To me, “proof of work” feels a little like the internal combustion engine. It’s kind of dirty, and grew so big in our time that it needs huge amounts of power to continue to work (as in drilling for oil and fracking all the things to make cars go brrrr): it’s “what we have” (or “they” have, whatever) because for a while, every blockchain based cryptocurrency went for it.
Now, some people are not completely oblivious to how stupid this looks, and alternatives are slowly coming around (proof-of-stake for eth, consensus protocols for xlm, etc.). The future is looking brighter, but as for BTC it’s just too late: it’s expensive because it requires huge amounts of investments to exist and allow transactions.
Blockchain hype is pretty large source of free software funding that doesn’t corrupt the movement to serve a couple of oligarchs. Both offer freedom.
I am not fan of blockchain snake oil peddlers myself, but if they manage to convince a bunch of greedy, rich capitalists to lose some money on free software alternatives to the status quo, I am content.
Public smart contracts also incentivize research of formal methods, dependent typing and other methods to improve software correctness. Another great win.
As mentioned down-thread I think you mean “proof of work” and not “blockchain” here. Git repos use a merkle-tree block-chain just like Bitcoin, for example, and there’s no proof of work there.
I also think it’s ilkely you misunderstand the nature of “wasted resources” in a proof of work algorithm (blockchain related, or otherwise) but that’s a side issue here.
This stance comes from a place of ignorance on how energy is generated and converted into proof-of-work. It’s a shame because blockchains are here to stay and will only grow in consumption. The majority of electricity in use by proof-of-work chains today comes from excess hydro energy. This is energy that was already harvested and would go to waste if it wasn’t used to secure bitcoin. There are today several large projects looking to do the same: make use of excess energy harvested by power plants, and turn them into money. There is really no need to create new energy to power cryptocurrencies. That, I agree is a waste, and completely unnecessary.
Whoa, wait a minute. That’s like how I can buy the meat in the supermarket without being responsible for animals being slaughtered because the animals have already been slaughtered anyway, right? There’s no market involved here or anything.
I know this rationale very well and I think truth is somewhere in the middle. Yes, mining is clearly a way to turn that excessive (in off-peak hours) energy into useful work. BUT! ATM any other, potentially more useful way of turning this energy into useful work needs to compete with miners. Potentially, that energy could create aluminum, fill water tanks, charge huge batteries, etc.
Also, the way demand supply/demand for hashing power works - in times of high prices of BTC (like now) people are likely to run miners everywhere, not just next to large power stations in off-peak hours.
I’m a bit confused by this project’s status. Since last time this was shared
the website has been remade and the old articles are gone. Is this some kind of relaunch? Are the people behind the old radicle still around?
Funnily enough, the article makes no mention of blockchain, while the community discourse shows that monadic.xyz appears to be funding radicle development and is looking for blockchain developers to work on it. This still seems to be tied to oscoin.io, quite curious where the money for this keeps coming from.
Hej, thanks for the questions.
It’s less of relaunch and more of an update on our development. After launching last year, we learned a lot from early users and iterated on our design to focus the direction of the project. We’ve been communicating these changes as we process them (see here and here) — this post is simply an attempt to present those changes and realign the public direction of the project. The website has been redesign to reflect these changes. All previous work on the project still exists in the old repo.
Monadic does indeed fund development on the Radicle project and did fund the oscoin.io project. oscoin has been sunsetted as a “product” and the research that went into it will instead be implemented within the Radicle project (see new website). The article does indeed (second to last paragraph) mention this approach with the presentation of the global registry that holds canonical project metadata. On “where the money comes from”: Monadic is funded by the partners presented on the website and Radicle is — and will remain — a free and open source project.
Hope this provides more clarity! More frequent updates on development will be shared on the community discourse.
Why not use email as the transport layer. Already supported in git.
See https://lobste.rs/s/gyygl3/advantages_email_driven_git_workflow
It has been considered piggybacking on email for the distribution of patches at least. It falls short when it comes to questions of code hosting, public visibility and generally encoding primitives of code collaboration (open/close state of issues, same for patches/pr). Where it could be leveraged in the future is for notifications of updates to projects one follows.
I know next to nothing about IPFS so this is a genuine question: why is the Radicle network separate from the main IPFS network? Does this mean that if I want to use both IPFS and Radicle then I need two daemons?
For you second question: yes - they run independently of each other.
They are separated as we don’t replicate general files, you can’t really make use of them without being in the context of radicle. A better way is to think of ipfs as the technology we picked for replication and not the ipfs network which one partakes when starting the default ipfs daemon.
The main reason is that currently IPNS name resolutions take a much longer time in a larger network. It seems like we’ll soon have fixes for that, so in theory we could move back to using the main network.
But can’t you use IPFS proper, while just ignoring IPNS for now? I thought the latter is just an extra layer over the former?
We use both - IPFS for storing the data, and IPNS to point to the head of the list/log of expressions to a machine. Thus, when you update a machine (e.g., add a new issue), you’re adding an item to IPFS that has the new data plus a pointer to the old data, and updating the IPNS to point to that. When someone reads, they resolve the IPNS, and then read the corresponding data.
In theory we could implement such a pointer system ourselves, or use something other than IPNS. But it seems like improvements to IPNS are happening faster than we could come up with an alternative, so we settled on IPNS.
Ah, so you’re using a separate IPFS network because the normal one is too big for IPNS now, and yours is still at an early stage, thus small enough that IPNS is fast enough? If yes, then please do move to normal IPFS as soon as you find that the improvements make it feasible. And, for the sake of future generations, please don’t use an “It’s too late” argument to avoid such a move. It won’t be.
I’ve only skimmed the site, but what it appears to be missing is a way for users to submit issues. That’s one of the major things (other than discoverability) that Github adds over git itself.
Have you checked the rad issue command? It brings a lot of the issue functionality - that people are used to from github - to the table.
Not specifically, but everything I’ve seen appears to require to you to install radicle and then use the command line. I have an OSS project on github with a couple of thousand users, many of whom aren’t particularly technical. One the main benefits I get from github is that my users can report bugs or request features very simply.
Oh! I really like this. I just did the tutorial and I had a problem when running
rad project init. It exits withApart from this, is there any easy way to apply a patch locally without accepting it to test changes? Because I guess once you’ve accepted it that is already merged for everyone.
There is now documentation for patch checkout: https://radicle.xyz/docs/index.html#rad-cli-reference
With that you should be able to accept the patch locally in a fresh checkout of the project somewhere else on your filesystem, this way exercissing the process of proposing of accepting entirely locally.
Hej, glad you took it for a spin. How did you install radicle? And is the git-remote-ipfs binary in your path?
I installed it from source using stack. I don’t know right now, not home. Will check later when I arrive and get back to you. I’m installing it right now at the work computer to see if I have the same problem also.
When installing from source you need to follow the steps on how-to install ipfs and the git-remote-ipfs helper as described in this section: https://github.com/radicle-dev/radicle#installation
Ouch! Completely missed that.