bunch of missing

content/community/get-involved.md

@@ -0,0 +1,5 @@
+---
+title: "Community"
+---
+
+Connect with us through the following platforms:

content/developers/apps/index.md

@@ -0,0 +1 @@
+### Apps

content/developers/documentation/index.md

@@ -0,0 +1,3 @@
+---
+name: "Documentation"
+---

content/developers/platform/index.md

@@ -0,0 +1 @@
+# Platform

content/resources/blog/1074-weekly-dev-meeting-progressing-towards-network-stability.md

@@ -0,0 +1,29 @@
++++
+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.

content/resources/blog/1081-weekly-dev-meeting-network-integration-testing-and-squashing-final-bugs.md

@@ -0,0 +1,26 @@
++++
+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.

content/resources/blog/1097-weekly-dev-meeting-enhancing-connection-stability-and-finalizing-transport-fixes.md

@@ -0,0 +1,60 @@
++++
+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.

content/resources/blog/1127-weekly-dev-meeting-gateway-deployment-freenet-chat.md

@@ -0,0 +1,40 @@
++++
+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.

content/resources/blog/456-mitigating-sybil-attacks-in-freenet.md

@@ -0,0 +1,61 @@
++++
+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.

content/resources/blog/799-proof-of-trust-a-wealth-unbiased-consensus-mechanism-for-distributed-systems.md

@@ -0,0 +1,54 @@
++++
+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.

content/resources/blog/882-zero-knowledge-proofs-and-anonymous-reputation-in-freenet.md

@@ -0,0 +1,85 @@
++++
+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.