diff --git a/content/about/history/index.md b/content/about/history/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/about/media/index.md b/content/about/media/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/about/philosophy/index.md b/content/about/philosophy/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/about/team/index.md b/content/about/team/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/community/events/index.md b/content/community/events/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/community/forums/index.md b/content/community/forums/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/community/get-involved.md b/content/community/get-involved.md new file mode 100644 index 00000000..84d5966d --- /dev/null +++ b/content/community/get-involved.md @@ -0,0 +1,5 @@ +--- +title: "Community" +--- + +Connect with us through the following platforms: diff --git a/content/community/get-involved/index.md b/content/community/get-involved/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/community/support/index.md b/content/community/support/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/developers/apps/index.md b/content/developers/apps/index.md new file mode 100644 index 00000000..b30c6a9e --- /dev/null +++ b/content/developers/apps/index.md @@ -0,0 +1 @@ +### Apps diff --git a/content/developers/contribute/index.md b/content/developers/contribute/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/developers/documentation/index.md b/content/developers/documentation/index.md new file mode 100644 index 00000000..30266d2b --- /dev/null +++ b/content/developers/documentation/index.md @@ -0,0 +1,3 @@ +--- +name: "Documentation" +--- \ No newline at end of file diff --git a/content/developers/getting-started/index.md b/content/developers/getting-started/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/developers/platform/index.md b/content/developers/platform/index.md new file mode 100644 index 00000000..ca5f6cd0 --- /dev/null +++ b/content/developers/platform/index.md @@ -0,0 +1 @@ +# Platform 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 new file mode 100644 index 00000000..aea6f05f --- /dev/null +++ b/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. 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 new file mode 100644 index 00000000..66b80244 --- /dev/null +++ b/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. 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 new file mode 100644 index 00000000..31e42307 --- /dev/null +++ b/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. 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 new file mode 100644 index 00000000..f1003eca --- /dev/null +++ b/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. diff --git a/content/resources/blog/456-mitigating-sybil-attacks-in-freenet.md b/content/resources/blog/456-mitigating-sybil-attacks-in-freenet.md new file mode 100644 index 00000000..a4f5d2f6 --- /dev/null +++ b/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. 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 new file mode 100644 index 00000000..b4808272 --- /dev/null +++ b/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. 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 new file mode 100644 index 00000000..653f483b --- /dev/null +++ b/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. 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 new file mode 100644 index 00000000..d68f8c68 --- /dev/null +++ b/content/resources/blog/900-weekly-developer-meeting-updating-state-and-performance-optimizations.md @@ -0,0 +1,42 @@ ++++ +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/content/resources/case-studies/index.md b/content/resources/case-studies/index.md new file mode 100644 index 00000000..e69de29b diff --git a/content/resources/faq/index.md b/content/resources/faq/index.md new file mode 100644 index 00000000..b3dff837 --- /dev/null +++ b/content/resources/faq/index.md @@ -0,0 +1,159 @@ ++++ +name = "FAQ" ++++ + +- [What is Freenet?](#what-is-freenet) +- [How does Freenet work?](#how-does-freenet-work) +- [What is the project's history?](#what-is-the-projects-history) +- [How do the previous and current versions of Freenet differ?](#how-do-the-previous-and-current-versions-of-freenet-differ) +- [Why was Freenet rearchitected and rebranded?](#why-was-freenet-rearchitected-and-rebranded) +- [What are the key components of Freenet's architecture?](#what-are-the-key-components-of-freenets-architecture) +- [Who is behind Freenet?](#who-is-behind-freenet) +- [What is the status of Freenet?](#what-is-the-status-of-freenet) +- [Can anyone use Freenet?](#can-anyone-use-freenet) +- [Can I follow Freenet on social media?](#can-i-follow-freenet-on-social-media) +- [How can I financially support Freenet development?](#how-can-i-financially-support-freenet-development) + +## What is Freenet? + +Freenet is a fully decentralized, peer-to-peer network and a drop-in replacement for the world wide web. It operates as +a global shared computer, providing a platform for sophisticated decentralized software systems. Freenet allows +developers to create decentralized alternatives to centralized services, including messaging, social media, email, and +e-commerce. It\'s designed for simplicity and flexibility and can be used seamlessly through your web browser. The +platform\'s user-friendly decentralized applications are scalable, interoperable, and secured with cryptography. + +## How does Freenet work? + +Freenet is a global key-value store that relies on +[small world routing](https://en.wikipedia.org/wiki/Small-world_routing) for decentralization and scalability. Keys in +this key-value store are [WebAssembly](https://en.wikipedia.org/wiki/WebAssembly) code which specify: + +- When is a value permitted under this key? + - eg. verify that the value is cryptographically signed with a particular public key +- Under what circumstances may the value be modified + - eg. modifications must be signed +- How can the value be efficiently synchronized between peers in the network + +These webassembly keys are also known as [contracts](https://docs.freenet.org/components/contracts.html), and the values +are also known as the contract\'s **state**. + +Like the web, most people will interact with Freenet through their web browser. Freenet provides a local +[HTTP proxy](https://docs.freenet.org/components/ui.html) that allows data such as a +[single-page application](https://en.wikipedia.org/wiki/Single-page_application) to be downloaded to a web browser. This +application can then connect to the Freenet peer through a [websocket](https://en.wikipedia.org/wiki/WebSocket) +connection and through this interact with the Freenet network, including creating, reading, and modifying contracts and +their state. + +For a much more detailed explanation please see our [user manual](https://docs.freenet.org/introduction.html). + +## What is the project's history? + +Freenet was initially developed by Ian Clarke at the University of Edinburgh in 1999 as a decentralized system for +information storage and retrieval, offering users the ability to publish or retrieve information anonymously. + +In 2019, Ian began work on a successor to the original Freenet, which was internally known as \"Locutus.\" This project, +a redesign from the ground up, incorporated lessons learned from the original Freenet\'s development and operation, and +adapted to today\'s challenges. In March 2023, the original version of Freenet was separated into its +[own project](https://www.hyphanet.org/pages/about.html), and what was known as \"Locutus\" was officially branded as +\"Freenet.\" + +## How do the previous and current versions of Freenet differ? + +The previous and current versions of Freenet have several key differences: + +- Functionality: The previous version was analogous to a decentralized hard drive, while the current version is + analogous to a full decentralized computer. + +- Real-time Interaction: The current version allows users to subscribe to data and be notified immediately if it + changes. This is essential for systems like instant messaging or group chat. + +- Programming Language: Unlike the previous version, which was developed in Java, the current Freenet is implemented in + Rust. This allows for better efficiency and integration into a wide variety of platforms (Windows, Mac, Android, + MacOS, etc). + +- Transparency: The current version is a drop-in replacement for the world wide web and is just as easy to use. + +- Anonymity: While the previous version was designed with a focus on anonymity, the current version does not offer + built-in anonymity but allows for a choice of anonymizing systems to be layered on top. + +## 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 modern challenges. The +original Freenet, although groundbreaking, was built for an earlier era. + +This isn\'t the first time Freenet has undergone significant changes. Around 2005, we transitioned from version 0.5 to +0.7, which was a complete rewrite introducing \"friend-to-friend\" networking. + +In March 2023, the original Freenet (developed from 2005 onwards) was spun off into an independent project called +\"Hyphanet\" under its existing maintainers. Concurrently, \"Locutus\" was rebranded as \"Freenet,\" also known as +\"Freenet 2023,\" to signal this new direction and focus. The rearchitected Freenet is faster, more flexible, and better +equipped to offer a robust, decentralized alternative to the increasingly centralized web. + +It is important to note that the maintainers of the original Freenet did not agree with the decision to rearchitect and +rebrand. However, as the architect of the Freenet Project, and after over a year of debate, Ian felt this was the +necessary path forward to ensure the project\'s continued relevance and success in a world very different than when he +designed the previous architecture. + +## What are the key components of Freenet's architecture? + +Delegates, contracts, and user interfaces (UIs) each serve distinct roles in the Freenet ecosystem. Contracts control +public data, or \"shared state.\" Delegates act as the user\'s agent and can store private data on the user\'s behalf, +while UIs provide an interface between these and the user through a web browser. See the +[user manual](https://docs.freenet.org/components/overview.html) for more detail. + +## Who is behind Freenet? + +Freenet was started by Ian Clarke in 1999 and grew out of his undergraduate +[paper](https://cs.baylor.edu/~donahoo/classes/5321/papers/C99.pdf) \"A Distributed Decentralized Information Storage +and Retrieval System.\" + +To further the goals of the project, Ian Clarke and Steven Starr co-founded The Freenet 501c3 non-profit in 2001. + +In 2024, the Freenet non-profit board of directors consists of Ian Clarke, Steven Starr, and Michael Grube, with Ian +serving as President and Steven as Chief Strategy Officer. Along with Ian, the development team consists of Nacho Duart +and Hector Alberto Santos Rodriguez. + +## What is the status of Freenet? + +As of June 2024, we are very close to getting the network up; see our [blog](https://freenet.org/blog) for regular +status updates. In the meantime you can already [experiment](https://docs.freenet.org/tutorial.html) with building a +decentralized app to test on your own computer. + +## Can anyone use Freenet? + +While Freenet is designed to be accessible to most users, approximately 10-20% of users might experience connectivity +issues due to being behind symmetric NATs or restrictive firewalls. These network configurations, often implemented by +ISPs, can prevent direct peer-to-peer connections, which are essential for Freenet\'s decentralized network. Users +behind such configurations might also face difficulties with other applications requiring low-latency connections, such +as multiplayer games and VoIP services. We recommend choosing ISPs that offer less restrictive NAT configurations to +ensure a better overall internet experience and seamless use of Freenet. + +## Can I follow Freenet on social media? + +Yes, you can follow [\@FreenetOrg](https://twitter.com/freenetorg) on Twitter/X or discuss +[r/freenet](https://www.reddit.com/r/Freenet/) on Reddit. + +## How can I financially support Freenet development? + +Founded in 2001, Freenet is a 501c3 non-profit organization dedicated to the development and propagation of technologies +for open and democratic information distribution over the Internet. We advocate for unrestricted exchange of +intellectual, scientific, literary, social, artistic, creative, human rights, and cultural expressions, free from +interference by state, private, or special interests. + +#### Donate via PayPal or Credit Card + +[](https://www.paypal.com/donate?hosted_button_id=EQ9E7DPHB6ETY) + +#### Donate via Cryptocurrency + +Freenet is **not** a cryptocurrency, but we do accept cryptocurrency donations. For large donations (over \$5,000) +please contact us before sending. For smaller donations, please use the following wallets: + +Cryptocurrency Address + +--- + +Bitcoin + Zcash + Ethereum diff --git a/content/resources/tutorials/index.md b/content/resources/tutorials/index.md new file mode 100644 index 00000000..e69de29b diff --git a/themes/freenet/static/fontawesome/webfonts/fa-brands-400.ttf b/themes/freenet/static/fontawesome/webfonts/fa-brands-400.ttf new file mode 100644 index 00000000..774d51ac Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-brands-400.ttf differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-brands-400.woff2 b/themes/freenet/static/fontawesome/webfonts/fa-brands-400.woff2 new file mode 100644 index 00000000..71e31852 Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-brands-400.woff2 differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-regular-400.ttf b/themes/freenet/static/fontawesome/webfonts/fa-regular-400.ttf new file mode 100644 index 00000000..8a9d6344 Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-regular-400.ttf differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-regular-400.woff2 b/themes/freenet/static/fontawesome/webfonts/fa-regular-400.woff2 new file mode 100644 index 00000000..7f021680 Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-regular-400.woff2 differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-solid-900.ttf b/themes/freenet/static/fontawesome/webfonts/fa-solid-900.ttf new file mode 100644 index 00000000..993dbe1f Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-solid-900.ttf differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-solid-900.woff2 b/themes/freenet/static/fontawesome/webfonts/fa-solid-900.woff2 new file mode 100644 index 00000000..5c16cd3e Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-solid-900.woff2 differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-v4compatibility.ttf b/themes/freenet/static/fontawesome/webfonts/fa-v4compatibility.ttf new file mode 100644 index 00000000..ab6ae224 Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-v4compatibility.ttf differ diff --git a/themes/freenet/static/fontawesome/webfonts/fa-v4compatibility.woff2 b/themes/freenet/static/fontawesome/webfonts/fa-v4compatibility.woff2 new file mode 100644 index 00000000..9027e38b Binary files /dev/null and b/themes/freenet/static/fontawesome/webfonts/fa-v4compatibility.woff2 differ diff --git a/themes/freenet/static/js/main.js b/themes/freenet/static/js/main.js new file mode 100644 index 00000000..76a56863 --- /dev/null +++ b/themes/freenet/static/js/main.js @@ -0,0 +1,24 @@ +document.addEventListener('DOMContentLoaded', () => { + // Get all "navbar-burger" elements + const $navbarBurgers = Array.prototype.slice.call(document.querySelectorAll('.navbar-burger'), 0); + + // Check if there are any navbar burgers + if ($navbarBurgers.length > 0) { + + // Add a click event on each of them + $navbarBurgers.forEach(el => { + el.addEventListener('click', () => { + + // Get the target from the "data-target" attribute + const target = el.dataset.target; + const $target = document.getElementById(target); + + // Toggle the "is-active" class on both the "navbar-burger" and the "navbar-menu" + el.classList.toggle('is-active'); + $target.classList.toggle('is-active'); + + }); + }); + } + }); + \ No newline at end of file