See also:
https://news.ycombinator.com/item?id=40469711 - Ian Clarke explains the next generation of Freenet [video] (2023)
Show HN: Freenet, a peer-to-peer platform for decentralized apps
21–30 of 302 posts
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#22Notably this project was conceived by a backroom decision to dump the original Freenet development team's work, in favor of a rewrite from different developers, without asking anyone on the original team. It was an ivory tower decision which was announced on the mailing list without prior discussion. The old team did not agree, yet it was forced through by a decision of the "board". The "board" was a group of people…
> Notably this project was conceived by a backroom decision to dump the original Freenet development team's work, This is a false narrative, from the Freenet FAQ[1]: Why was Freenet rearchitected and rebranded? In 2019, Ian began developing a successor to the original Freenet, internally named “Locutus.” This redesign was a ground-up reimagining, incorporating lessons learned from the original Freenet and addressing…
> and after over a year of debate
There was no "year of debate".
You came to the mailing list and announced it for the first time as a finalized decision already,
without any prior debate with the original team.
The "board" you cited as the body which allegedly discussed it did neither join the mailing list discussion,
nor were you willing to hand out their contact info.
It's all public for anyone to see on the mailing list archive:
https://www.mail-archive.com/devl@freenetproject.org/msg5526...
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#23I think better approach for "ghost keys" would be requiring X amount of crypto to be sent to 0x0 (burning). Current implementation (requiring donation to freenet) basically gives freenet foundation infinite reputation (including any other potential project that would accept ghost keys as identity), kinda breaking the decentralization aspect
Ghost keys will ultimately be just one of a menu of options for bootstrapping reputation in a decentralized reputation system. They have the advantage of simplicity, anonymity, and helping to fund the project, but as you correctly point out - they are centralized.
A cryptocurrency-based solution like you suggest will undoubtedly be one of a menu of reputation bootstrapping options that will develop over time.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#24Earlier quoted context omitted.
> Notably this project was conceived by a backroom decision to dump the original Freenet development team's work, This is a false narrative, from the Freenet FAQ[1]: Why was Freenet rearchitected and rebranded? In 2019, Ian began developing a successor to the original Freenet, internally named “Locutus.” This redesign was a ground-up reimagining, incorporating lessons learned from the original Freenet and addressing…
> and after over a year of debate There was no "year of debate". You came to the mailing list and announced it for the first time as a finalized decision already, without any prior debate with the original team. The "board" you cited as the body which allegedly discussed it did neither join the mailing list discussion, nor were you willing to hand out their contact info. It's all public for anyone to see on the maili…
> There was no "year of debate".
Incorrect, I raised the issue with the lead maintainer over a year prior to that announcement.
> You came to the mailing list and declared it as a finalized decision.
As the project's architect I'm entitled to make decisions about the project's future direction.
> It's all public for anyone to see on the mailing list archive:
> https://www.mail-archive.com/devl@freenetproject.org/msg5526...
I stand by every word I said in that mailing list thread.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#25Earlier quoted context omitted.
I'm very glad to hear that—the anonymity of the original Freenet has led to it being a very unsavory place that was more well known for CSAM then anything positive or useful. As an outsider, it sounds like this new direction is the right choice for Freenet to try and attract new users and fulfill the team's original goals.
Extremely depraved things are not the only thing to use freedom of speech for, and freely speaking can result in all kinds of repressions. And even without agreeing on whether people should be anonymous on the Internet, it could be agreed that replacing a software which guards against a certain threat model (repressions) with one which does not, without changing the name, is not exactly a wise decision.
The new Freenet will support the creation of anonymity systems as services on top of it, which is much better architecturally than tying the platform to one approach to anonymity as I did when I designed the original Freenet.
We will also have a decentralized reputation system that will protect people from being exposed to unsavory or illegal content, a common criticism of the old Freenet architecture.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#26Very cool project! > We've developed a unique (AFAIK) solution to the consistency problem, every contract must define a "merge" operation for the contract's associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you'll get the same end result. Where can I learn more about this? How is this different from CRDTs/CmRDTs?
I'm also curious about this. I don't understand how deletion and modification can be made commutative operations in a way that makes sense
tombstones are sorta the default answer here (i.e. at simplest, you keep all data forever so you can merge correctly, but you hide anything where you've seen a tombstone after it).
but "makes sense" and ways to optimize that can change massively with context. e.g. for a chat app, as soon as you see "deleted message X", you can reasonably drop X and all past and future changes to X because they won't be shown by anyone (don't even need to sync them). if you do that with "deleted chars 87..93" in a text editor, past-edits that you receive in the future might affect the behavior (it might add chars before those, changing what that range means), so you can't simply forget those chars (e.g. an easy option is to replay all events that occur after an event syncs, but that means retaining all events forever). the semantics you choose and what you do with the data affect your outcomes a lot.
tbh this is one of the reasons I like the idea of a WASM-defined algorithm. no one algorithm will be "best" for all data, and the storage/computation/transmission savings can be extreme.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#27Notably this project was conceived by a backroom decision to dump the original Freenet development team's work, in favor of a rewrite from different developers, without asking anyone on the original team. It was an ivory tower decision which was announced on the mailing list without prior discussion. The old team did not agree, yet it was forced through by a decision of the "board". The "board" was a group of people…
So he forked the project and went his own way. I am not sure I see the issue here. This is how we do open source on the internet. You don't have to join him, but he also has the right to go his own way too.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#28Very cool project! > We've developed a unique (AFAIK) solution to the consistency problem, every contract must define a "merge" operation for the contract's associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you'll get the same end result. Where can I learn more about this? How is this different from CRDTs/CmRDTs?
> Very cool project!
Thank you!
> Where can I learn more about this?
If you don't mind watching a video I gave this talk back in March that should be fairly comprehensive: https://youtu.be/3SxNBz1VTE0?si=R4ifrsfEUJfvjDPx
If you would prefer an article I recommend: https://freenet.org/about/news/summary-delta-sync/
> How is this different from CRDTs/CmRDTs?
It's very closely related, you can view Freenet contract state as a CmRDT, where the details of the merge operation are specified in the webassembly contract.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#29Very cool project! > We've developed a unique (AFAIK) solution to the consistency problem, every contract must define a "merge" operation for the contract's associated state. This operation must be commutative, meaning that you can merge multiple states in any order and you'll get the same end result. Where can I learn more about this? How is this different from CRDTs/CmRDTs?
I'm also curious about this. I don't understand how deletion and modification can be made commutative operations in a way that makes sense
It depends on the nature of the data, for example in our group chat app River[1] it stores the most recent messages - deleting the oldest to make room for the newest as necessary. Banning a user will remove them from the members list along with their messages, and recently banned users are stored in a banned list (like a tombstone).
So there is no one approach to this, rather you design the approach based on the application, and since contracts are just webassembly they are extremely flexible.
Re: Show HN: Freenet, a peer-to-peer platform for decentralized apps
#30Earlier quoted context omitted.
I'm also curious about this. I don't understand how deletion and modification can be made commutative operations in a way that makes sense
tombstones are sorta the default answer here (i.e. at simplest, you keep all data forever so you can merge correctly, but you hide anything where you've seen a tombstone after it). but "makes sense" and ways to optimize that can change massively with context. e.g. for a chat app, as soon as you see "deleted message X", you can reasonably drop X and all past and future changes to X because they won't be shown by anyon…
Exactly, well put.