Background A standalone instance of Abstract SDK can act as a personal blockchain operating system installable on any new CosmWasm rollup spun up with Rollkit. It allows your rollup, your personal chain, to be the center of the Interchain, communicating with other chains over IBC using Abstract's interchain communication protocol.

Problem: The interchain is incredibly fragmented, and only getting worse. Hundreds of thousands of chains will exist in the future thanks to new rollup frameworks like Rollkit, and it's a PITA to manage individual wallets, accounts, and applications on those chains. I just want to use the apps! I don't want 10 different wallets for all the chains. Secondly, all my finances are spread across every chain, and I have no central place of access to control them.

Solution myOS (your OS) puts you at the center of the Interchain. It gives you the power to to interact with any protocol on any chain (connected via IBC) directly from your rollup. You can even choose to have a separate account for every DeFi protocol you interact with, making your accounting easier.

Every one of your accounts can have a different security profile. Want to sign in with passkey? No problem. No-sign transactions when you're moving around tokens in internal accounts? No problem. Triple factor authentication with confirmation from your account on Neutron? No problem. Everything is an Account.

Personal Chain Benefits

• Single source of identity across every chain, also allowing you to accrue reputation
• Better indexing, because every action you perform originates from one place, not random chains
• Fully sovereign financial applications - run all of your personal finances and financial strategies on your own chain. This is actually something we're calling MyFi.
• Personal content ID registry for content attribution.

Considerations Yes, of course we need state proofs before personal chains (at least personal rollups) become viable at all. And no, they don't technically need to be blockchains, but they need to be something deterministic and verifiable.

Interchain Mail (⛓️📧)

One of the first (and arguably most useful) applications of the Internet was e-mail, allowing individuals to send messages to one another over the Internet.

The first app available on myOS is Interchain Mail, allowing you to send messages to other users of myOS in the rollup ecosystem. This also supports multi-hop messaging as long as you specify the route upon which the message will travel.

Features: Implemented:

• Send / receive messages to users on the same chain
• Send / receive messages to users on other chains over IBC
• Sending messages to users by namespace (username)
• Send messages to users on other chains with hops in between

Desired:

• Batch messages in the server (request the server to send certain messages by ids, and then the server will reach out to the clients to send the messages. This allows for batching messages to save on gas costs)
• Callback on messages to update their sending status. Also should support designating actions to perform on failure.
• Reply to messages by ID
• messages to groups
• Sending to "namespace@remote.local" (frontend?)
• Sending funds in messages (attachments)
• Sending NFTs in messages (attachments)
• Contacts module
• Support for multiple versions of the client
• (frontend) Encrypting messages with the recipient's public key

Architecture:

Server (Adapter)

• Routes messages
  • Locally
  • Over IBC
• Resolves namespaces
• Stores pending messages not yet received by users (in the case they don’t have the app installed)
• Check client versions, and ensure message compatibility

Client (App)

• Stores messages
• Interacts with the server

Tech Interchain Mail uses Abstract's module-to-module communication protocol to allow the mail servers on different chains to communicate with one another. See the docs here. It can authenticate the sending module (and account) to ensure that the message is coming from a proper source. This is performed with an incredibly simple API, and its use in IBC mail can be seen here.

Use Cases

Yes, while this implementation is obviously highly inefficient, it can be highly useful. Imagine:

• A DAO being able to "mail" participants on-chain to vote on their proposals, giving them options to reply to and auto-vote.
• You being able to track referrals to protocols by interchain mail.
• Provable messaging with encrypted off-chain messages.
• Sending messages that can only be opened when funds are sent back.

Fun fact

Before SMTP was created, there were many competing email protocols, one of which was UUCP: Unix to Unix CoPy. UUCP allowed for routing messages between different servers via "bang paths" source such as "neutron!user" or if it went multi-hop, "neutron!juno!user". We have implemented a similar naming convention for ibc mail addresses.

Tech

myOS

What is an Operating System, or OS? Defined by Oxford Dictionary, an OS is “the software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals.” The primary function of an OS is to interface between the user and the computer hardware.

myOS interfaces with the different native modules on the rollup like your OS interfaces with peripherals.

myOS is a standalone instance of Abstract SDK, which is typically shared among many users. By having a standalone instance, it gives you full control over:

• Accounts
• Applications
• Namespaces
• Name Service
• Security and operations

Hackathon

Interchain Mail was developed entirely during the hackathon, and was forked from the Abstract app-template. It is deployed on Adair's personal rollup spun up using Rollkit and currently communicates with Archway Testnet, which can be seen in the demo video. I attempted multiple times to connect my rollup to Rosm testnet, though the RPC endpoints proved to be entirely unreliable (as with my own rollup).