Decentralized Chat App Collaboration Proposal: Any.org ↔ Anoma.net

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:

  1. Connecting two identities: a decentralised mechanism for establishing connections, minimizing spam, and maximizing relevant connections.
  2. Connecting identities and group channels: a decentralised mechanism for joining channels, protecting against spam and bots.
  3. Connecting identity and sync provider: a mechanism to make sync-provider deals (e.g., 10 GB for $10/year).
  4. 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

  1. Frictionless for Good Actors: People who genuinely know each other should be able to connect with a single click—no hurdles.
  2. Deterring Malicious Actors: Repeatedly abusing the network or spamming should become prohibitively expensive. Offenders face escalating penalties that make large-scale abuse unsustainable.
  3. 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:

  1. Network-Wide Reputation & Crypto-Economic Incentives
  2. Global Contact Book with Private Profiles
  3. 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

  1. 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.
  2. 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:

  1. Direct Connection (You already know me)
  2. 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:

  1. Minimum TRUST: The sender must meet a min-TRUST threshold to keep them out of the spam folder.
  2. 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.
  3. 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:

  1. Number of in-mails you have is limited.
  2. With higher TRUST and ANY locks, you have more in-mails available.
  3. If the requested connection faces a lot of in-mail requests that are rejected, then their threshold of required TRUST will be increased.
  4. 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

  1. Hidden Social Graph: Who is connected to whom remains private, avoiding public on-chain relationship data.
  2. Opt-In Identity Disclosure: Users decide which personal details to share during connection requests.
  3. Real Identities Encouraged: While pseudonymity is possible, the system incentivizes verifying your real identity or known social handles to build TRUST.
  4. Selective Visibility: Users can specify which groups or individual connections can see which private fields.

6. Putting It All Together

  1. 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.
  2. Reward for Contributing: Active community members who contribute value (and thus earn ANY, increasing their TRUST) gain greater freedom to connect.
  3. Spammers Punished: Multiple rejections or spam flags lead to escalating TRUST and ANY token burns, making mass spam cost-prohibitive.
  4. 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

  1. Scalability: Channels should support many members without bottlenecks or manual overhead.
  2. Granular Access Control: Channel owners need a robust yet flexible way to manage who can join, read, or contribute.
  3. Privacy & Autonomy: Membership lists and channel content remain encrypted; owners and members decide what metadata is disclosed (if any).
  4. 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

  1. Private Channels: Membership is by invitation only (invites come from the owner or trusted members).
  2. 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

  1. Token Holdings: “Members must hold at least 3 ETH.”
  2. Membership in Another Channel: “Must already be in ‘Berlin-Creatives’ channel” or “Must have membership in a certain DAO.”
  3. Reputation Requirements: “TRUST score must exceed a given threshold.”
  4. Paid: “Paid $10” or “Has a subscription of $5/month”.
  5. 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:

  1. Alice is in the channel A.
  2. Alice has a direct connection with Bob.
  3. Alice sends an “invite to channel A” to Bob.
  4. 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):

  1. In-Mail: The channel member sends an invite request to the target user’s Social Inbox.
  2. TRUST Threshold: The sender needs a high enough TRUST level (and other signals) to ensure their invite is not flagged as spam.
  3. 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.

We look forward to working with the Anoma team to refine, prototype, and eventually deploy this solution for the next generation of decentralized communication.

10 Likes

First of all, thank you for this fantastic proposal.

What I really like is that it considers the entire lifecycle of a user and puts trust and data privacy in the center of all interactions. This includes on-boarding & bootstrapping new users, discovery, user profiles, spam-protection, as well as identifying inactive users and legacy accounts.

Personally, I would like to see a prototype of the any-to-any protocol and I will share some thoughts and comments how we could realize it. I will focus on the first two cases that you’ve suggested

that seem to fit very well with the stage the Anoma protocol is currently in.

TRUST / ANY

  • We have a token application supporting regular as well as soulbound tokens (SBTs).
  • Delegation is straightforward to add.
  • In our next private devnet phase, we will support time constraints in the resource logic necessary for trust to decay over time.

Discovery & Privacy

  • Private discovery will be possible once our shielded resource machine is integrated. Connection requests could then be submitted so that only the potential counterparty or a solver can see them.
  • Solving mutual connection intents could also be done locally by one of the parties wanting to connect, and doesn’t necessarily require a 3rd party solver. This requires the other party’s intent to be public.
  • One could also imagine a group of people wanting to connect, e.g., to do an activity together requiring at least n participants
  • For channel permissions and ACL, you can potentially make use of Anoma’s composable identities. We could think about whether this can be integrated into your protocol.

I would personally be happy to explore this further, starting with a first prototype for case 1.

3 Likes

Thank you for the lovely post! I’m very excited about Anytype – both as an application which could benefit from Anoma, and as a product which I want to use personally (and I have used some earlier versions, although not recently).

I’m curious: does this include chats? For example: if I am in a large group chat where only part of the group chat is on my local network, and I’m disconnected from the broader internet, will I see messages from the subset of the group chat on my LAN?

In general, for which parts of the data (e.g. messages) and metadata (e.g. membership, permissions) associated with channels do you need (or want) a total order, and for which parts is a partial order (DAG / CRDT) sufficient? Happy to read existing protocol documentation if applicable. I ask because this will help us figure out how to separate concerns between Anoma resource machine state (totally ordered) and CRDT state (partially ordered).

From these two descriptions, I infer that in your imagined world the Anoma resource machine-managed state would include at least:

  1. Connections (between users), and rules governing how they can be created or altered.
  2. Channel membership registries, and rules governing how they can be updated. The list of channel members may not be stored directly “on-chain”, but it would be referenced (e.g. with some kind of commitment) and thereby tracked.

Is that accurate?

Just as a note, we have conducted research into a “service commitment” system designed for expressely this sort of purpose (and others of a similar nature), which you can find described in a paper here. We have not yet implemented this; it is planned for a future devnet/testnet. I believe the flow that you have described corresponds pretty closely to “service requests” and “service offers” as described in the paper. Happy to prioritize this for a future devnet/testnet if it’s something that would be helpful for your use-case.

At a high level this approach makes a lot of sense to me, and although we’re also interested in integrating CRDT / partially-ordered state management into Anoma in the future, we’ve made much more progress so far on the totally-ordered (resource machine-managed) state – so this seems like a smart synthesis. We’ll also take a look at any-sync and see what we can learn (and if we have any ideas to contribute there). Paging @tg-x who has the most context on this aspect of network protocol design from our end.

This all makes sense to me. As a note, in general, you can make zero-knowledge proofs about any state represented as resources in Anoma, and reveal exactly whatever data you want to reveal (to whomever you send the proof). We have not yet built all of the developer tooling around this, but the state architecture is designed to be compatible with it, and you can create ephemeral resources to pass around proofs of specific properties in intents.

I think that this makes sense as a first PoC. To better understand your requirements (and potential future deployments), I wanted to ask whether you have preferences about what “chain backend” is used here. The Anoma devnets & testnets will offer a simple backend (hosted initially by Heliax, and later on by community operators), and you can also host one yourselves using the node software if you like. Another option could be to use an existing EVM chain as the backend (where the Ethereum protocol adapter would allow you to run an Anoma resource machine application). Are there preferences or plans on your end that we should keep in mind here?

3 Likes

Thank you very much @pronkin!

In addition to the two notes that Chris brought up on this, I would like to take the opportunity and ask more specifically how we can be helpful in achieving the outlined four next steps.

Would it e.g. help to start collaboratively defining certain resource objects / parts of the necessary code or would you prefer pulling help for specific questions along the way? Have the build and learn sections on the Anoma Developer Documentation been helpful so far? I’m happy to go with any level of collaboration and support you feel comfortable with.

2 Likes

Thank you for your kind response. We are equally excited about Anoma! Love the idea behind and what affordances it offers. We look forward to exploring potential integrations. Anytype is still in its early phase, in the next two to three months, we expect significant improvements that will make it more elegant and user-friendly. I would be happy to personally guide you through onboarding whenever you are ready.

Yes, you will only see messages from people within the group on the local network. any-sync already supports peer discovery in local networks using mDNS. Once this group, or any peers within it, connects to the internet, they will synchronize and exchange the latest state. The messages from the local network will then be merged into the state of the peers connected to the internet.

Access control lists (ACL) for a channel require a total order, while the changes to objects within the channel can be managed using a CRDT-style partial order. You can find high-level information about any-sync in the documentation linked here.

Yes, this is how I imagine it with my current knowledge.

Thank you for sharing the paper. The idea of using formalism to elegantly address real-world challenges like service commitments and trust in distributed systems is indeed intriguing. From my quick review, it appears to be well-aligned with the mentioned case. Implementing such logic also would require further development in any-sync , particularly support for multiple sync providers within a single topology. Given our current roadmap, we anticipate working on this in 2026, so it is not a priority. However, we would be happy to coordinate efforts once all the prerequisites are in place.

We would appreciate any feedback or suggestions, @tg-x. I have attached the high-level documentation here, and we are available to provide a more detailed explanation if that would be helpful.

We have considered EVM-based rollups as a potential starting point, but we remain open to using any appropriate chain backend—especially if your team can support us directly via your devnet or testnet. We look forward to hearing your recommendation on which path might be most optimal.

4 Likes

Hey! Thanks for the detailed write-up and the pointers to the docs, I’m taking a look and going to share my thoughts on the topic soon.

1 Like

Makes sense - that’s awesome! Exactly how I hoped such an app might work. :slight_smile:

Yes, I see. Thanks for the link, we’ll take a look.

Understood, thanks for the context. We’ll keep this in mind.

Understood.

1 Like

Thanks a lot for suggesting different ways to move forward! The documentation provides a good starting point, but we still need to overcome the challenge of adapting to the new stack. The Build and Learn sections have been helpful, though additional guidance on certain aspects would be beneficial.

We’d be happy to do an offline whiteboarding session to better understand where we might need more of your expertise and collaborate on defining certain resource objects.

2 Likes