Hello Anoma!
Let’s explore a collaboration to create a decentralised communication network built on trusted connections.
About us: we are Any association. We are developing a set of protocols and tools with a mission to bring digital independence to anyone, anywhere. Our network has grown to 500,000+ identities/wallets, 10 million objects (chats, pages, databases), 768 self-hosted subnetworks. Today the network is powered by one application for non-crypto people, Anytype, a collaborative wiki for nerds.
This year we are going to launch a simple chat app, called Any app. It features independent communication channels and provides an alternative to cloud social networks on a private social graph (Telegram, WhatsApp, WeChat, Discord). It will focus on Berlin creatives as the first niche.
Opportunity: there are no quality communication tools that respect your privacy and autonomy at the same time. All the best tools like Telegram, Signal and iMessage are centralised. We see an opportunity in building a communication network of independent channels no single party controls.
Key features of the any app:
Real-Time Messaging: send and receive messages instantly, similar to Telegram or Signal, with support for 1:1 chats and group chats of up to 100,000 members.
Permissionless Ownership of Identity and Social Graph: retain full control of your identity and connections without relying on centralized authorities. Your connections are yours—no one can stop you from communicating.
Physical Ownership with Local-First Data: all content is stored locally on your device and synced using our CRDT-based protocol (any-sync), ensuring you retain complete control over your data in communication channels.
Offline-Friendly & Fast: with CRDTs, messages sync automatically when you’re back online, and the user experience remains smooth, even in low-connectivity environments.
End-to-End encryption & verification: every message and file transfer is cryptographically secured—only intended recipients can access the content. Every change in a channel is cryptographically signed.
No provider lock-in & peer-to-peer sync: you can host your own any-sync node for greater autonomy and privacy. Devices on the same local network can communicate and sync data directly without relying on the internet.
Multi-Format: chats, pages, lists: bring superpowers to messaging with a built-in block-based document editor and integrated database support with multiple view options. A local API can be used by a local agent, enabling powerful on-device automation and integrations.
Coming later:
- Community & Forum Features: this autumn, we plan to introduce one-to-many channels and community groups with sub-channels, like in Discord and Slack. Threaded discussions on posts will create a seamless, forum-like experience.
- Marketplaces and Discovery: in collaboration with Anoma, we aim to introduce global and local contact books, spam protection, decentralized & private discovery for public channels, members, and groups, plus paid channel subscriptions, private endorsements, referrals, and integrated marketplace mechanics—empowering communities to run their own marketplaces smoothly.
We see this is possible with on-chain identities and off-chain communication channels where every change is cryptographically signed and encrypted.
We’ve built a local-first communication protocol any-sync. It syncs encrypted channels at scale and is optimised for speed. any-sync is based on CRDTs.
The main primitive of any-sync is an independent communication channel, structured as an encrypted Directed Acyclic Graph (DAG). These multimedia channels support chats, pages, and shared databases. Channels belong to their creators, the list of members is private to the channel, and every interaction is verifiable and end-to-end encrypted. Once a connection is established, no one can intercept it and access its contents. These channels can sync in a peer-to-peer way and via any-sync nodes that can be self-hosted and hosted by a sync provider.
We believe our network and products can benefit from anoma network: connections between members and joining channels in our decentralised network with a private social graph need to be seamless and frictionless. The mechanism should discourage spam, bots and impersonations and keep the network permissionless.
Network wide reputation and crypto-economic incentives are our solutions to this problem. However, using public blockchain to establish connections makes the social graph public, something we want to avoid. We see potential in using anoma solvers and intents as a solution to the problem. Adding the anoma layer could enable parties that don’t know each other to establish a connection and make deals while maintaining the privacy of the social graph.
Tldr, here’s how we think we can collaborate:
- Connecting two identities: a decentralised mechanism for establishing connections, minimizing spam, and maximizing relevant connections.
- Connecting identities and group channels: a decentralised mechanism for joining channels, protecting against spam and bots.
- Connecting identity and sync provider: a mechanism to make sync-provider deals (e.g., 10 GB for $10/year).
- Referral program (deals): decentralised referrals where channels earn fees for referring identities that qualify criteria to other channels.
We want to explore each case separately, starting from the first two, as they could be the most useful for making our product valuable now.
The first problem to solve: Some of the biggest challenges of any communication network are the discovery of others and establishing connections. Cloud social networks use centralised control to solve these problems. This centralised control strips participants of digital freedoms. Even with centralised control , cloud networks are polluted with spam, bots, and impersonations that are expected to grow exponentially with advances of the LLM era.
The decentralised network faces an even larger challenge: when anyone can connect to anyone, how do you enable good players to not feel any limitations and at the same time discourage spam, bots, and impersonations – all while keeping the network permissionless?
We want to work with the anoma team to build an any-to-any protocol to solve discovery and handshake problems in a decentralised network with a private social graph.
Here’s how it could work in practice (inspired by the anoma “Multichat” idea and solver-based approach):
- User A wants to chat with User B: User A posts an intent, such as “I want to establish a direct channel with B.” A solver checks if A meets B’s requirement (for example, min TRUST of 10, or direct invitation from a known contact). If matched, the solver finalises an on-chain handshake. Off-chain, A and B exchange encryption keys to form an any-sync direct channel.
- User A wants to join Channel C: Suppose Channel C is invite-only, with a rule like “members must hold 3 ETH or must have a channel invitation token.” User A posts an intent proving via zero-knowledge that they hold 3 ETH. The solver completes the handshake, registering A on the channel’s membership contract. Off-chain, A’s any-sync client obtains the encryption keys from the channel’s coordinator.
- Provider Deals: A user with a large space wants a sync provider. They publish an intent: “Need 10 GB storage for up to 10 ANY/year.” A provider (X) that has staked 1,000 ANY can respond with an offer. The solver matches them, and finalises the contract on-chain, and the user’s any-sync space begins replicating to the provider’s infrastructure.
- Referral Deals (example): A channel wants to attract new members who meet certain criteria – say they must have at least 500 TRUST or hold a particular SBT. The channel publishes a referral offer, stating: “We will pay 50 ANY tokens for each successful referral that meets our requirements.” A user (the referrer) finds someone who fits the criteria and posts an intent: “I want to refer this new member to Channel X.” The solver verifies the new member’s credentials (e.g., their TRUST level or SBT ownership) and, upon acceptance, triggers an on-chain payout of the 50 ANY tokens to the referrer. Channel membership data remains off-chain and encrypted by any-sync.
Throughout these steps, the heavy data (actual messages, files, membership lists) never goes on-chain. anoma’s solver-based approach coordinates the matching and minimal on-chain state for reputations, stakes, and membership references, while any-synchandles the end-to-end encrypted communication off-chain.
Feasibility & Benefits:
- Privacy-First & Scalable: By combining local-first encryption with off-chain data and minimal on-chain logic (intents, matching, membership proofs), the system can scale to large user bases without sacrificing privacy.
- Permissionless Yet Accountable: All membership “rules” and “handshakes” can be open to anyone who satisfies them, while spam and abuse are disincentivised by crypto-economic costs and reputational penalties.
- Composable: The referral program, sync-provider marketplace, or direct connections seamlessly integrate with the same anoma-based mechanism for discovering and fulfilling user intents.
The Vision: If we build Any this way, following the lines described in Anoma’s “Draft RFC: Dreaming of Multichat,” we would use a hybrid approach: minimal but critical logic on-chain (intents, membership, deals, reputation updates), and any-sync for the actual data encryption, storage, and real-time collaboration. This synergy would bring:
- anoma’s solver-based matching to handle invites, channel membership, provider deals, and referrals in a trust-minimised, privacy-preserving way.
- Any’s local-first, CRDT-based any-sync for fast, user-friendly experiences that do not rely on a single server or central authority.
- Crypto-economic incentives (TRUST, ANY tokens, locking, referral rewards) enforced on-chain, ensuring that spam and malicious behavior are financially unprofitable.
The result is a decentralised communication network that merges the best of both worlds – anoma’s private intent matching and Any’s local-first, user-owned data model.
Together, we can create a true alternative to cloud communication platforms – one that prioritises privacy, empowers autonomy, and stays open for anyone to build economies on top of it. The Anoma network can benefit from both our existing community and the new users we plan to onboard, as they will naturally integrate into the Anoma ecosystem. We’re excited to hear your thoughts and explore how we can collaborate to bring this vision to life!
More in-depth description of cases:
A Deep Dive One: Connecting Two Identities
1. Overview: Direct Channels
When two members of the network decide to connect, they establish a direct channel—a dedicated communication channel that only those two parties can access. These direct channels:
- Rely on any-sync for local-first, end-to-end encrypted messaging.
- Are completely independent once established (no external server or centralized authority can intercept or moderate them).
- Grant access rights only to the two participants; no one else can peek into the conversation or metadata.
2. The Core Problem
In a truly decentralized system, anyone can message anyone. Without careful safeguards, this opens the floodgates for:
- Spam and irrelevant communication
- Phishing, impersonation, and social engineering attacks
- Bot-driven or AI-generated mass messaging, particularly as large language models become more advanced
Traditional social platforms rely on centralized control (algorithms, user data, moderation teams) to mitigate these threats—but this strips participants of digital freedoms. A decentralized network needs a permissionless mechanism to keep spam in check without creating a walled garden or demanding personal data from users.
3. Targeted End Result
- Frictionless for Good Actors: People who genuinely know each other should be able to connect with a single click—no hurdles.
- Deterring Malicious Actors: Repeatedly abusing the network or spamming should become prohibitively expensive. Offenders face escalating penalties that make large-scale abuse unsustainable.
- Permissionless Yet Private: Everyone can participate, but private information and social graphs are protected from prying eyes.
4. Ideas for Solutions
Below are the core building blocks that could enable trusted, spam-resistant communication:
- Network-Wide Reputation & Crypto-Economic Incentives
- Global Contact Book with Private Profiles
- Social Inbox Model (Direct Connections vs. “In-Mails”)
4.1 Network-Wide Reputation: TRUST
What is TRUST?
- Non-Transferable Reputation: Each network member has a TRUST score, represented as a soul-bound token that cannot be traded nativly.
- Earned, Not Bought: TRUST increases only when you contribute to the network in ways that matter—e.g., receiving compensation in the network’s native token (ANY) for meaningful contributions. TBD.
- Locked to Identity: Because TRUST is non-transferable, it is “locked” to your identity (soul-bound). You cannot buy or sell it on the open market without selling an identity.
- Governance Weight: TRUST works in tandem with the ANY token for governance decisions, reflecting both your stake and your reputation.
- Long-Term Decay: TRUST decays over ~100 years, ensuring that long-inactive or legacy accounts do not permanently retain high reputation.
How to Acquire TRUST
- Invitation by a Current Member: New users can be invited by someone who delegates a portion of their own TRUST to jumpstart the newcomer’s reputation. This approach leverages social trust networks, incentivizing members to invite only reputable people.
- Self-Guarantee (Burn ANY for TRUST): Users without a direct invite can “bootstrap” a limited amount of TRUST by burning ANY tokens. This ensures a base-level reputation so they can still communicate without being auto-routed to spam folders.
Why TRUST may work
- It discourages spam because repeated malicious attempts burn reputation.
- It ensures that your standing in the network can’t be “bought” wholesale and used to impersonate or spam.
- Over time, a consistent track record of good behavior builds lasting credibility.
4.2 Global Contact Book with Private Profiles
Global contact book is an ability to find other people by their public names/hashes.
Public vs. Private Fields
Each identity can create a decentralized name (similar to ENS) and maintain a profile with both public and private fields:
- Public Fields: Display name, who invited you (inviter’s ID), date of joining, your current TRUST level, verified social accounts, etc.
- Private Fields: Personal details like email, phone number, social handles, or channels you participate in. These remain hidden from the general public.
Controlled Disclosure
When requesting a connection, a user can choose to reveal some private fields to the recipient (e.g., phone number, verified Twitter handle) to prove authenticity or relevance. Recipients see only the information you explicitly share—no more.
When accepting a connection, a user can also choose to reveal some fields.
Benefits
- Simplifies identity verification in a selective and privacy-preserving manner.
- Allows for a consistent, user-friendly naming system that also ties into on-chain reputation (TRUST).
4.3 Social Inbox Model
Every identity (and channel) in the network has a Social Inbox:
- Connection Requests: Potentially valuable new connections or direct messages appear here.
- Spam Folder: Low-reputation or random messages from untrusted sources are automatically routed here.
We propose two main types of connection requests:
- Direct Connection (You already know me)
- In-Mail (Potentially relevant new contact)
Direct Connections
A direct connection is for people who claim they already know each other. The process is as follows:
- Minimum TRUST: The sender must meet a min-TRUST threshold to keep them out of the spam folder.
- Private Fields: The sender discloses specific private fields (e.g., full name, a known phone number) to show they’re someone the recipient already knows.
- Recipient’s Decision:
- Accept → A direct channel is formed. Messages are encrypted and synced via any-sync.
- Reject → Negative signal for the sender. Each rejection burns a portion of the sender’s TRUST and ANY tokens, with escalating penalties for repeated rejections.
Why This Works
- If you truly know the recipient, acceptance should be easy.
- Malicious actors sending random claims of “knowing” people risk heavy penalties if those recipients reject them as strangers.
In-Mails
An in-mail is for reaching out to someone you don’t know but have a potentially relevant reason to connect with:
- Number of in-mails you have is limited.
- With higher TRUST and ANY locks, you have more in-mails available.
- If the requested connection faces a lot of in-mail requests that are rejected, then their threshold of required TRUST will be increased.
- Recipient’s Decision:
- Accept → A direct channel is established (same as above).
- Mark as Spam → This negatively impacts the sender’s in-mail privileges (limiting future in-mails) and may result in burned TRUST if abuse is consistent.
Why This Works
- High-TRUST users can more freely introduce themselves to new contacts, reflecting the fact they’ve built a reputation.
- Potentially relevant outreach is still possible in the network without a known personal connection.
- Automated “cold outreach” spam is deterred by the cost of losing TRUST through repeated rejections.
5. Privacy Requirements
- Hidden Social Graph: Who is connected to whom remains private, avoiding public on-chain relationship data.
- Opt-In Identity Disclosure: Users decide which personal details to share during connection requests.
- Real Identities Encouraged: While pseudonymity is possible, the system incentivizes verifying your real identity or known social handles to build TRUST.
- Selective Visibility: Users can specify which groups or individual connections can see which private fields.
6. Putting It All Together
- Minimal Friction for Known Contacts: If two people already know each other, they can connect with almost no overhead—especially if both have positive TRUST.
- Reward for Contributing: Active community members who contribute value (and thus earn ANY, increasing their TRUST) gain greater freedom to connect.
- Spammers Punished: Multiple rejections or spam flags lead to escalating TRUST and ANY token burns, making mass spam cost-prohibitive.
- Permissionless Yet Private: Anyone can join and attempt to connect. The system remains open, but malicious and reckless behavior is financially and reputationally penalized.
7. Next Steps for Collaboration
- Technical Feasibility: Explore how Anoma’s intents and solvers can facilitate private “connection requests” and on-chain trust management without exposing the entire social graph.
- Zero-Knowledge Tools: Investigate ways to prove that certain TRUST thresholds or “trusted invitors” exist without revealing all details on-chain.
- PoC for Direct Connections: Start with a proof-of-concept focusing on direct connections, verifying that the penalty mechanics and trust scoring function as intended in a live environment.
- Future Integration: Once direct connections are stable and secure, expand the approach to group channels, sync-provider deals, and referral programs.
Conclusion
Connecting two identities in a decentralized network is a complex challenge: frictionless, private communication for legitimate users protected from spam and abuse, especially at scale. Our approach—combining non-transferable TRUST tokens, a selective disclosure profile system, and a Social Inbox with built-in penalties—strikes a balance between open participation and effective spam control.
We believe Anoma’s privacy-preserving mechanics can further strengthen this model, ensuring that reputation and handshake processes can run without leaking sensitive social graph data.
A Deep Dive Two: Group Channels
In contrast to direct channels (one-to-one connections), open channels are collective spaces where multiple members can communicate and collaborate. Examples include chat rooms, forums, shared wikis, or co-editable documents and lists—any group-oriented context where participants share content and conversation.
Key Goals for Open Channels
- Scalability: Channels should support many members without bottlenecks or manual overhead.
- Granular Access Control: Channel owners need a robust yet flexible way to manage who can join, read, or contribute.
- Privacy & Autonomy: Membership lists and channel content remain encrypted; owners and members decide what metadata is disclosed (if any).
- Permissionless Growth: While channels can be open to large audiences, the network should still guard against spam, infiltration, or bots.
1. Who Can Enter Channels
Default Membership Rules
- Channel Owner: The original creator of the channel. By default, they can invite others.
- Core Members: Individuals explicitly invited by the owner (or by other trusted members who have invite privileges).
- Extended Network: If certain rules allow it, additional participants can join automatically (or with minimal friction).
Private vs. Open Channels
- Private Channels: Membership is by invitation only (invites come from the owner or trusted members).
- Open (or Partially Open) Channels: Members can be automatically admitted if they meet certain criteria set by the owner. For example, “Must hold at least 3 ETH” or “Must already belong to a specific subnetwork or "channel.”
- Paid channels are a special case of open channels. These are channels where you get access or membership if you paid fee or subscription.
2. Rule-Based Access Control (ACLs)
One of the most powerful features of open channels is the ability to define Rule-Based ACLs (Access Control Lists). The channel owner can specify on-chain and off-chain conditions that must be satisfied for automatic entry.
Examples of Rule-Based ACLs
- Token Holdings: “Members must hold at least 3 ETH.”
- Membership in Another Channel: “Must already be in ‘Berlin-Creatives’ channel” or “Must have membership in a certain DAO.”
- Reputation Requirements: “TRUST score must exceed a given threshold.”
- Paid: “Paid $10” or “Has a subscription of $5/month”.
- Combination Rules: “Member of channel X and holds 3 ETH, or was directly invited by an existing channel member.”
How It Works
- On-Chain Verification: A solver or intent mechanism (potentially powered by Anoma) checks if a candidate meets the specified condition (e.g., 3 ETH in a verified wallet).
- Off-Chain Encryption: The channel remains fully end-to-end encrypted; only those who pass the rule check and complete the handshake have the decryption keys.
- Automatic Admission: If the rule is satisfied, the user can join without needing manual approval—streamlining onboarding for large communities.
Owner Override: The channel owner (or designated admins) can also manually approve or reject membership requests, even if the user meets or fails the criteria. This offers flexibility for edge cases.
3. Invitation Mechanics
Invitations by Direct Connections
“Only people with a direct connection can invite other members to channels (by default).”
By default, an existing channel member can only invite people they have a direct connection with in the network. This ensures:
- Verification: You’re not randomly inviting strangers or untrusted accounts you’ve never interacted with.
- Security: Malicious actors with low reputation can’t easily flood a channel with unwanted participants—they’d need a direct link to an established member.
Workflow Example:
- Alice is in the channel A.
- Alice has a direct connection with Bob.
- Alice sends an “invite to channel A” to Bob.
- Bob accepts; he’s automatically added to the channel’s member list and gains access to the channel’s encrypted data.
Invitations Outside Your Network: In-Mails
“Invitations to channels outside of direct network are in-mails.”
If a channel member wants to invite someone they do not have a direct connection with, they must send an in-mail invitation (the same concept as a direct connection in-mail):
- In-Mail: The channel member sends an invite request to the target user’s Social Inbox.
- TRUST Threshold: The sender needs a high enough TRUST level (and other signals) to ensure their invite is not flagged as spam.
- Recipient’s Decision:
- Accept → The user is granted a direct channel with the inviter (if needed) and also gets access to the group channel.
- Reject/Spam → Negative feedback is logged, potentially penalizing the sender’s ability to send future invites.
This mechanism keeps spammers in check: repeated rejection and spam reports result in burned TRUST or token penalties, preventing large-scale channel infiltration attempts.