Dev Diary | August 31, 2026
Status: In development and technical exploration
Foldinglink is not being built as another feed that happens to mention decentralization. The goal is to give community members a clearer relationship with their files, their transactions, and the groups they participate in. That means the work has to happen in several connected places at once: personal nodes, file transfer, community exchange, messaging, and governance.
This is our Week Two build overview. It is a progress report, not a product launch announcement.
The four lines of work
1. Files and downloads: make the file path visible
The first question is simple: after a user shares or requests a file, can they tell where it is, what is happening, and when it is ready?
Foldinglink's whitepaper describes a model in which a creator's content can start from a personal NAS node and move through a peer-to-peer network. The important user experience is not the acronym behind the network. It is the ability to follow a file from upload to storage to download, with useful status information along the way.
The current work includes a download-task management module. It maps task status, progress, and storage path into the client, and it normalizes total and completed bytes so progress can be calculated consistently. The team is also adapting to different interface response shapes and adding failure fallbacks.
2. Community transactions: make exchange easier to verify
The second line is the foundation for a community economy. A member should be able to understand whether a transaction was created, signed, recorded, completed, or interrupted.
The whitepaper frames this as a way for creators and participants to exchange resources without leaving the community context. At this stage, we are not presenting a finished marketplace or a live token economy. The team has built a working foundation around order flow, a TradeEscrow contract, chain interaction, signature checks, and transaction storage. In parallel, the team is exploring an OP Stack-based Layer 2 test environment connected to Ethereum Sepolia.
The purpose of this exploration is to test whether the rules of an exchange can be made clear and verifiable without making every user understand blockchain infrastructure. The OP Stack is described by its official documentation as an open-source framework for building Ethereum Layer 2 networks, but Foldinglink's own network design is still being evaluated.
3. Groups and messaging: make membership more than a list
Groups are where a network becomes a community. Users need to create a group, find public groups, request access, approve members, and receive messages reliably across devices.
The current group work is in development. Wallet ID generation, group creation, public search, join requests, and membership approval have been implemented in the current build. The team is now connecting the messaging path across mobile clients and NAS nodes. That includes message streams, authentication, encryption, duplicate prevention, and history recovery after a connection becomes ready.
libp2p's official documentation explains peer-to-peer networking as communication among peers rather than a traditional client-server relationship. It also describes publish/subscribe as a pattern that can support chat rooms and file-sharing coordination. Those concepts help explain the direction, but they do not mean Foldinglink's group system is finished or production-ready.
4. Governance: make difficult decisions visible
The community review room, or "jury room," is one of the areas where the product idea becomes a real operating problem. What happens when members disagree about content, delivery, or a transaction? Who can submit evidence? How is a decision recorded? What can be appealed?
The product prototypes for the jury room have been completed, while the functionality and governance rules remain in development. The whitepaper identifies decentralized governance and the economic model as important open problems. We want those decisions to be discussed with users rather than hidden behind a finished-looking interface.
What is already complete, and what is still moving?
The community home and NAS management areas are at an initial completed stage and are not the main focus of this week's build. File transfer, community transactions, groups, and governance are still at different stages of development. Some foundations are implemented; some interfaces are being integrated; some architecture choices are still under exploration.
That distinction matters. A roadmap is useful only when it tells people what they can expect to see next, not when it turns every idea into a promise.
Why build these pieces together?
In a conventional app, files, messages, payments, and moderation can look like separate product areas. In Foldinglink's model, they affect one another. A creator may share a file from a personal node, discuss it with a group, exchange it for community points, and rely on a review process if something goes wrong.
Building one piece without the others would leave users with a collection of disconnected screens. The current work is about making the path legible: a personal node stores and serves resources; a transaction records the exchange; a group carries the relationship; governance provides a way to handle disagreement.
What we are watching next
The next useful proof will not be a larger list of technical terms. It will be clearer demonstrations of the user path:
- Can a user see a file's status and storage path without guessing?
- Can a user tell the difference between a pending, completed, and failed transaction?
- Can a group member receive history after a connection is restored?
- Can a participant understand how evidence, judgment, and appeal are supposed to work?
We will keep answering those questions as the build moves forward. The next posts will go deeper into the file path and community transactions, one user problem at a time.