diff --git a/content/blog/index.md b/content/blog/index.md deleted file mode 100644 index 25a8eeeb..00000000 --- a/content/blog/index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Blog" -date: 2024-06-24 -draft: false ---- \ No newline at end of file diff --git a/content/resources/blog/1074-weekly-dev-meeting-progressing-towards-network-stability.md b/content/resources/blog/1074-weekly-dev-meeting-progressing-towards-network-stability.md deleted file mode 100644 index aea6f05f..00000000 --- a/content/resources/blog/1074-weekly-dev-meeting-progressing-towards-network-stability.md +++ /dev/null @@ -1,29 +0,0 @@ -+++ -title = "Weekly dev meeting - progressing Towards Network Stability" -date = 2024-05-03 -+++ - -### Summary: - -In this week's Freenet developer meeting, Ian Clarke and Ignacio Duart discussed significant advancements and remaining -challenges before getting the network up and running. The primary focus was on refining the connection and configuration -processes within Freenet's system. Key highlights include: - -- **Configuration Management**: The developers have implemented a system to set and save default configurations, which - are crucial for initializing and maintaining stable operations after restarts. The configuration files are currently - managed using TOML due to its robust support in Rust. - -- **Connection Stability and Logic Errors**: Recent developments have mostly resolved previous issues with connection - stability. However, some logic errors persist in the connect operation, affecting how peers establish and maintain - connections. The team is close to resolving these, with a few last adjustments needed. - -- **Testing and Network Simulation**: Extensive local network testing is underway, aiming to mimic real-world conditions - as closely as possible before proceeding to broader network deployment. The team discussed strategies to handle - potential issues in a real-world environment, emphasizing the importance of robust testing phases. - -- **Developer Tools and Documentation**: Improvements in developer tools and documentation are in progress, with a - specific focus on enhancing the onboarding process for new developers through updated tutorials and guides. - -- **Upcoming Objectives**: The immediate goal is to finalize the current phase of testing, address the identified bugs, - and prepare for a public release. Parallel efforts are being made to prepare the infrastructure for wider testing and - eventual deployment. diff --git a/content/resources/blog/1081-weekly-dev-meeting-network-integration-testing-and-squashing-final-bugs.md b/content/resources/blog/1081-weekly-dev-meeting-network-integration-testing-and-squashing-final-bugs.md deleted file mode 100644 index 66b80244..00000000 --- a/content/resources/blog/1081-weekly-dev-meeting-network-integration-testing-and-squashing-final-bugs.md +++ /dev/null @@ -1,26 +0,0 @@ -+++ -title = "Weekly dev meeting - network integration testing and squashing final bugs" -date = 2024-05-11 -+++ - -In our latest dev meeting, we dove into the recent updates and challenges with the Freenet network protocol. Ignacio -shared the latest on our efforts to boost node connectivity and stability across the network. - -### What’s New: - -- **Stability and Bug Fixes:** We spent a good chunk of this week squashing bugs to make network connections more - stable. Ignacio explained the technical hurdles we’re tackling to keep connections between nodes reliable. It’s tricky - but we're making headway. -- **Integration and Testing:** We're knee-deep in integrating and manually testing the latest changes. We're also - working toward getting CI passing. This is key to catching regressions early and ensuring everything holds up under - stress. -- **Gateway Improvements:** We’ve made some solid progress on enhancing how gateways handle peer connections, which are - crucial for assimilating new nodes into the network. - -### What’s Next: - -- **Ramping Up Testing:** Now that we've nailed down most of the glaring issues, it’s time to push harder with more - comprehensive testing. We’re talking multiple nodes and gateways to really test the limits of scalability and - performance. -- **Tool Enhancements:** We're also planning to upgrade our network simulation tool, which is vital for a clear and - efficient view of what’s happening network-wide. diff --git a/content/resources/blog/1097-weekly-dev-meeting-enhancing-connection-stability-and-finalizing-transport-fixes.md b/content/resources/blog/1097-weekly-dev-meeting-enhancing-connection-stability-and-finalizing-transport-fixes.md deleted file mode 100644 index 31e42307..00000000 --- a/content/resources/blog/1097-weekly-dev-meeting-enhancing-connection-stability-and-finalizing-transport-fixes.md +++ /dev/null @@ -1,60 +0,0 @@ -+++ -title = "Weekly Dev Meeting - Enhancing Connection Stability and Finalizing Transport Fixes" -date = 2024-05-24 -+++ - -**Focus on Connection Stability and Transport Improvements** - -Our primary focus has been on enhancing the stability and functionality of the connection and transport layers within -Freenet. Ignacio has dedicated significant effort to address issues related to the connect operation and transport -mechanisms. We’ve identified and resolved several bugs, ensuring that connections are maintained properly and cleaned up -when lost. Although we haven’t fully tested all scenarios, the connect operation is now functioning as expected. - -**Handshake and Transport Challenges** - -One of the main challenges we’re facing is with the handshake process. While it works most of the time, there are -occasional failures. Ignacio is concentrating on debugging this aspect, particularly the handshake failures, using -various unit tests. These tests sometimes provide errors without clear explanations, making the debugging process more -time-consuming. - -**Refactoring and Streamlining Configuration** - -We have also polished the startup process of the Freenet binary. Previously, there were some duplications and misuse of -statics, which have now been addressed. We’ve moved towards a cleaner dependency injection model, reading configurations -at startup and ensuring consistency across different parts of the system. This has streamlined the startup process and -made it more robust. - -#### Upcoming Tasks - -**Testing and Integration** - -The next steps involve extensive testing to ensure that the fixes we’ve implemented are stable across various scenarios. -We need to integrate the recent changes and ensure that everything works cohesively. This includes creating physical -connections between nodes and testing the handshake process more thoroughly. - -**Improving Developer Experience** - -We’re also focusing on improving the developer experience. The example of the Ping contract has been simplified -significantly, making it a great “hello world” application to demonstrate the ease of developing on Freenet. We plan to -write guides and provide building blocks to help developers create their applications more efficiently. - -**Tooling and Debugging Enhancements** - -To aid in debugging, especially with multiple nodes, we are considering improving our logging and tracing tools. While -we already have some tools in place, they need refinement to better handle complex scenarios. Additionally, we might -invest time in fixing our transaction history UI, which is currently broken, to provide a clearer overview of operations -across nodes. - -#### Goals and Future Plans - -**Demo Preparation** - -We aim to prepare a demo for an upcoming talk on May 31st. The goal is to showcase the working aspects of Freenet, -particularly the Ping contract, to demonstrate its capabilities. This will be a significant milestone, allowing us to -show tangible progress and attract interest from potential users and contributors. - -**Long-term Vision** - -Our long-term vision includes making Freenet a plug-and-play solution where users can easily start nodes and interact -with decentralized applications. Achieving this will require continued effort to refine the network's stability, improve -the developer experience, and ensure seamless integration of all components. diff --git a/content/resources/blog/1127-weekly-dev-meeting-gateway-deployment-freenet-chat.md b/content/resources/blog/1127-weekly-dev-meeting-gateway-deployment-freenet-chat.md deleted file mode 100644 index f1003eca..00000000 --- a/content/resources/blog/1127-weekly-dev-meeting-gateway-deployment-freenet-chat.md +++ /dev/null @@ -1,40 +0,0 @@ -+++ -title = "Weekly Dev Meeting - Gateway deployment, freenet-chat" -date = 2024-06-10 -+++ - -**Freenet Chat Development:** - -- Ian has been working on the Freenet chat system and shared a specification document. He decided to focus on a - web-based interface rather than a command-line interface due to ease of implementation. -- A significant topic was the method for updating contracts within the network. Ian proposed a replace contract field - that allows for contract updates signed by the contract owner, similar to HTTP 301 redirects. - -**Technical Challenges and Solutions:** - -- They discussed the challenge of updating user-facing applications while maintaining contract versions. Ignacio - emphasized the need for a pattern to update the underlying code without disrupting the user experience. -- The team is focusing on stabilizing the current system and ensuring the robustness of the test suite to support quick - and reliable releases. - -**Configuration and Deployment:** - -- Ignacio demonstrated improvements in the node configuration, emphasizing the simplicity and reliability of the current - setup. -- There was a discussion on packaging and distributing the Freenet software, ensuring it runs smoothly on various - operating systems without requiring root access. -- They plan to create an optimized image for easy deployment, possibly using Docker, and explore automated deployment - triggered by CI/CD pipelines. - -**Gateway Management:** - -- They discussed setting up additional gateways on EC2 instances to ensure network stability, especially when Ian is - unavailable. -- Long-term plans include a decentralized system for gateway management to avoid single points of failure. - -#### Action Items: - -- Ian to continue working on the freenet-chat prototype. -- Improve node configuration and deployment processes. -- Set up additional gateways to ensure network reliability. -- Stabilize the system and prepare for a gradual rollout to a small group of testers. diff --git a/content/resources/blog/456-mitigating-sybil-attacks-in-freenet.md b/content/resources/blog/456-mitigating-sybil-attacks-in-freenet.md deleted file mode 100644 index a4f5d2f6..00000000 --- a/content/resources/blog/456-mitigating-sybil-attacks-in-freenet.md +++ /dev/null @@ -1,61 +0,0 @@ -+++ -title = "Mitigating Sybil attacks in Freenet" -date = 2022-06-26 -+++ - -Every node in the Locutus network has a _location_, a floating-point value between 0.0 and 1.0 representing its position -in the small-world network. These are arranged in a ring so positions 0.0 and 1.0 are the same. Each contract also has a -location that is deterministically derived from the contract's code and parameters through a hash function. - -The network's goal is to ensure that nodes close together are much more likely to be connected than distant nodes, -specifically, the probability of two nodes being connected -[should be](https://en.wikipedia.org/wiki/Small-world_routing) proportional to `1/distance`. - -A [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack) is where an attacker creates a large number of identities -in a system and uses it to gain a disproportionately large influence which they then use for nefarious purposes. - -In Locutus, such an attack might involve trying to control all or most peers close to a specific location. This could -then be used to drop or ignore get requests or updates for contract states close to that location. - -# Solutions - -1. [Increase the cost of creating a large number of nodes close to a specific chosen identities](#identity-creation-cost) -2. [Make it more difficult to target specific contracts](#location-hopping) -3. [Increase the cost of bad behavior by making other nodes in the network monitor for it and react accordingly](#peer-pressure) -4. [Use statistical anomaly detection to identify and thwart suspicious behavior](https://www.pivotaltracker.com/story/show/186472381) - -## 1. Identity Creation Cost - -### 1.1 Gateway assignment - -When a node joins through a gateway it must negotiate its location with the gateway first. This could be done by both -node and gateway generating a random nonce, hashing it, and sending the hash to the other. After exchanging hashes they -exchange their actual nonces which are combined to create a new nonce, and a location is derived from that. This -prevents either gateway or the joiner from choosing the location. - -#### 1.1.1 Attacks - -- Gateway and joiner could collude to choose the location - -### 1.2 IP-derived location - -- The location could be derived deterministically from the node's IP address, this could then be verified by any node - that communicates directly with it. - -#### 1.2.1 Attacks - -- Attackers could limit connections to peers they also control, which could then ignore a mismatch between their - location and their IP address. - -## 2. Location Hopping - -### 2.1 Replication - -A contract has multiple copies, each indicated by a contract parameter - the location of each copy will be pseudorandom. -A user could query a random subset of the copies to ensure that they receive any updates. If any copy has an old version -of the state then the user can update them by reinserting the latest version obtained from a different copy. - -### 2.2 Date hopping - -A contract contains a parameter for the current date, which will mean that the contract has a different location every -day. If today's contract is found to be missing it can be reinserted using an older copy. diff --git a/content/resources/blog/799-proof-of-trust-a-wealth-unbiased-consensus-mechanism-for-distributed-systems.md b/content/resources/blog/799-proof-of-trust-a-wealth-unbiased-consensus-mechanism-for-distributed-systems.md deleted file mode 100644 index b4808272..00000000 --- a/content/resources/blog/799-proof-of-trust-a-wealth-unbiased-consensus-mechanism-for-distributed-systems.md +++ /dev/null @@ -1,54 +0,0 @@ -+++ -title = "Proof-of-Trust: A Wealth-Unbiased Consensus Mechanism for Distributed Systems" -date = 2023-08-28 -+++ - -Traditional approaches to rate-limiting the creation of things like coins, tokens, and identities in distributed -networks rely on computational (proof-of-work) or financial barriers (proof-of-stake) as a source of scarcity. While -effective in some contexts, these methods are wasteful and unfairly favor those with more resources. - -#### What is Proof-of-Trust? - -Proof-of-Trust offers an alternative by utilizing the scarcity of reciprocal trust between individuals as the primary -resource for rate-limiting various network activities. Unlike existing models, Proof-of-Trust does not inherently favor -participants with greater computational power or financial means. - -#### The Prisoner's Dilemma Analogy - -In the classic Prisoner's Dilemma, two participants must choose between cooperating for mutual benefit or defecting for -individual gain at the other's expense. In a similar vein, Proof-of-Trust involves two existing network participants who -must decide to cooperate or defect when attempting to create a new user. - -Participants must first stake something of value—such as their ability to create new users for a set period. The outcome -varies based on their choices: - -1. **Both Cooperate**: A new user is created. -2. **One Defects**: The defector gains two new users under their control, while the other participant is penalized by - losing their staking privilege for a period. -3. **Both Defect**: Both participants are penalized. - -#### Flexibility of Outcomes - -The exact nature of the rewards and punishments is flexible and subject to further refinement. This allows for the -fine-tuning of incentives to achieve desired operational outcomes, such as controlling the rate of new user creation. - -#### Versatility in Application - -While the creation of new users serves as an illustrative example, Proof-of-Trust can be applied to a wide range of -network activities requiring some form of rate-limiting or conditional access. - -#### The Ethical and Practical Benefits - -Proof-of-Trust levels the playing field by not favoring those with more resources. In a world where social and economic -status often determines access and influence, this mechanism offers a more equitable way to participate in a network. - -Additionally, Proof-of-Trust naturally encourages meaningful human interaction. Because the system relies on trust -between participants, people are motivated to get to know each other better. This need for trust not only enhances -network security but also serves as a catalyst for building community and forming meaningful human connections. - -#### Legal Considerations - -Speculatively, joining the network could require users to consent to a legal agreement, collected by their sponsors. -Analogous to the [GNU General Purpose License](https://en.wikipedia.org/wiki/GNU_General_Public_License), this contract -would outline essential ethical norms and explicitly prohibits "cheating," including any form of coercive behavior. -Non-compliance would risk penalties or exclusion, reinforcing the network's foundation of mutual trust. diff --git a/content/resources/blog/882-zero-knowledge-proofs-and-anonymous-reputation-in-freenet.md b/content/resources/blog/882-zero-knowledge-proofs-and-anonymous-reputation-in-freenet.md deleted file mode 100644 index 653f483b..00000000 --- a/content/resources/blog/882-zero-knowledge-proofs-and-anonymous-reputation-in-freenet.md +++ /dev/null @@ -1,85 +0,0 @@ -+++ -title = "Zero-Knowledge Proofs and Anonymous Reputation in Freenet" -date = 2023-10-29 -+++ - -Zero-knowledge proofs are one of the most significant developments in cryptography since the invention of public-key -crypto in the 1970s. But what exactly are they, what are they useful for, and what is their relevance to Freenet? - -## What Are Zero-Knowledge Proofs? - -In essence, zero-knowledge proofs (ZKPs) allow one party to prove that they have some secret information, but without -revealing anything about the information itself. For example, you could prove that you have some data that satisfies a -certain condition like [hashing](https://en.wikipedia.org/wiki/Hash_function) to a particular value, without revealing -the data itself. - -## Why Are They Important? - -Zero-knowledge proofs serve as the backbone of various privacy-preserving technologies and applications. One of the most -notable examples is their use in anonymous cryptocurrencies like [Zcash](https://z.cash/). In a standard blockchain like -Bitcoin, transactions are visible to everyone to ensure that the same Bitcoins can't be spent twice, but this -transparency compromises user privacy. With ZKPs, Zcash allows users to transact without revealing the sender, receiver, -or transaction amount, thus preserving anonymity while maintaining the blockchain's security. - -Below we'll explore another application in anonymous reputation systems. This will allow users to establish trust or -credibility within a network without exposing their transaction history. - -## Why are they Important for Freenet? - -Freenet relies on a peer-to-peer network where data storage and computation happen on a machine you don't necessarily -trust. Then how do you ensure that these untrusted peers are executing the code honestly and aren't tampering with the -data, without revealing private information? Traditional cryptographic methods only go so far in verifying the integrity -of these remote operations. - -By using ZKPs, Freenet can run code on untrusted peers and cryptographically verify that these peers are behaving as -expected—without exposing the data being processed or stored. - -## An Anonymous Reputation System based on Zero-Knowledge Proofs - -This protocol serves as a conceptual framework for creating a trust system for transactions on Freenet, while preserving -user anonymity. It is not intended as a comprehensive or rigorous design, but rather as a basis for discussion and -further development. - -### 1. Initial Agreement: - -Alice and Bob agree to a transaction. They generate and exchange feedback tokens, in which each signs the other's public -key together with a unique transaction ID. The protocol will be described below from Alice's perspective but typically -it will be used in both directions. - -### 2. Transaction: - -The transaction proceeds as intended between Alice and Bob. - -### 3. Alice generates a feedback receipt: - -After the transaction, Alice prepares her feedback whether positive or negative. Using a zero-knowledge proof mechanism, -she combines her feedback with Bob's token to generate a receipt. The receipt verifies: - -- That Alice and Bob are not the same person -- That Alice has a valid feedback token from Bob -- That Alice is the one providing feedback -- That Alice and Bob are entitled to participate in the reputation system - -The receipt does **not** reveal: - -- Alice's identity - -### 4. Alice logs her feedback: - -Alice then logs her feedback on Bob's public feedback record on Freenet, which verifies the receipt generated by Alice. -This record is non-repudiable, meaning that it cannot be modified by Bob. - -The essence of this protocol is to allow users to provide transaction feedback anonymously. Zero-knowledge proofs ensure -the feedback is genuine and linked to the correct transaction, keeping the process transparent yet private. This -anonymity fosters a trustworthy environment for transactions on Freenet, making it a more reliable platform for users -who prioritize privacy. - -## Conclusion - -Zero-knowledge proofs are almost magical, but they also come with a drawback: computational cost. Generating a -zero-knowledge proof can take seconds to minutes, depending on the proof's complexity. This delay is a hurdle in -real-world applications where quick transactions are essential. - -Despite these challenges, the technology is progressing rapidly. One noteworthy tool is -[RISC Zero](https://www.risczero.com/), which allows you to write nearly any Rust code and transform it into a -zero-knowledge proof. This is particularly suited to Freenet, which is implemented in Rust. diff --git a/content/resources/blog/900-weekly-developer-meeting-updating-state-and-performance-optimizations.md b/content/resources/blog/900-weekly-developer-meeting-updating-state-and-performance-optimizations.md deleted file mode 100644 index d68f8c68..00000000 --- a/content/resources/blog/900-weekly-developer-meeting-updating-state-and-performance-optimizations.md +++ /dev/null @@ -1,42 +0,0 @@ -+++ -title = "Weekly Developer Meeting: Updating State and Performance Optimizations" -date = 2023-11-22 -+++ - -We had a detailed technical discussion focusing on various aspects of our project, Freenet. Here's a breakdown of the -key points: - -1. **Contract Update Mechanism**: We tackled the contract update mechanism, crucial for handling the state (the - associated data) of contracts in our key-value store. This involves understanding how updates are initiated by - applications, the merging of states, and the process of sending updates to subscribers. - -2. **Update and Merge Process**: We discussed the specifics of how updates work, particularly focusing on the 'put' - operation. The conversation clarified how 'puts' are handled differently depending on whether the application is - already subscribed to the contract. A 'put' doesn't necessarily need a 'get' first. It's about merging states if the - contract exists and managing updates accordingly. - -3. **Handling Contract Interactions**: Our conversation covered how to handle interactions with contracts, including the - nuances of 'put' and 'update' requests. We clarified the terminology shift, where a 'put' is used when not subscribed - to a contract, and it can contain complete state or just a delta. An 'update' is more about when we are subscribed, - and it involves spreading changes across subscribers. - -4. **Subscription Mechanism and Network Propagation**: We went in-depth into the subscription mechanism, examining how - subscription requests are forwarded and managed across the network. This included discussing how updates propagate - through the network, both upstream and downstream, ensuring all peers have the latest state. - -5. **Routing and Simulation in the Network**: We explored network routing and how to simulate different network - conditions. This involved discussing the forwarding of requests and how to effectively simulate packet loss or - latency to test the network's resilience and efficiency. - -6. **Performance Optimizations**: We recognized the need for performance optimizations, especially related to speed. We - discussed the potential of moving away from libp2p for certain optimizations to enhance the system's performance. - -7. **Monitoring and Diagnostics for Simulations**: We planned to implement tools for monitoring and diagnostics during - simulations. This is to ensure we can track necessary data effectively and make informed decisions based on - simulation outcomes. - -8. **Future Development Focus**: We agreed on the importance of having a correct and functioning network before moving - into deeper optimizations, setting this as our future development priority. - -Overall, our discussion was a deep dive into the technicalities of Freenet, focusing on ensuring our network operations -are efficient, effective, and ready for future enhancements. diff --git a/hugo.toml b/hugo.toml index d3c45e62..4922d901 100644 --- a/hugo.toml +++ b/hugo.toml @@ -10,11 +10,6 @@ theme = "freenet" url = "/" weight = 1 - [[menu.main]] - name = "Get Started" - url = "/get-started/" - weight = 2 - [[menu.main]] name = "Developers" url = "/dev/" @@ -45,9 +40,8 @@ theme = "freenet" [[menu.main]] name = "Blog" - url = "/resources/blog/" + url = "/blog/" weight = 8 - parent = "Resources" [[menu.main]] name = "History"