...
Public Address Mappings, FIO Requests and OBT records. Even though these records are stored on-chain today, there is already an initiative on the Roadmap to consider moving it off-chain for performance reasons and another one to consider expanding the size of the associated content.
Request for Signature. Initial feedback received from wallets indicates a preference to store such requests off-chain.
Public Address Request and Friend List functionality. During the design of FIP-5, the requirement to store data on-chain created significant complexities. If the data can recorded anonymously off-chain, the FIO Privacy solution may be much simpler.
Push notifications. Off-chain messaging solution would likely make it simpler to develop a push notification mechanism for wallets.
Secure messaging. Ability to exchange messages between FIO Addresses has long been considered for development. Recently a community member has submitted a FIP-24: Secure Message Standard, which contemplates a solution similar to Layer 2 described here.
...
The solution would consist of nodes which would relay messages between FIO Protocol users to.
The message would be routed to recipient using FIO Addresses.
Recipient would fetch the message using their FIO Address or a search index contemplated in FIP-5 to further enhance privacy.
The messages would be signed with FIO Private Key which owns sender’s FIO Address.
The recipient would fetch the FIO Public Key which owns the sender’s FIO Address from the FIO Chain and use it to cryptographically validate that the message was created by the owner of the private key which owns the sender’s FIO Address.
The message could be further encrypted using Diffie-Hellman Key Exchange scheme similar to how FIO Request content is encrypted today.
...
Non-replicated - allow FIO Address owner to specify which node to use to send or receive L2 messages. Only that node would contain the relevant content. Similar approach has been described in FIP-24.
The downside of this approach is that:
Data can be irreversibly lost if the node is lost.
Data is not accessible if node is down or is being censored.
See related discussion regarding Request for Signature.
Replicated - the messages are simultaneously stored on and are accessible by querying any node.
The downside of this approach is that:
High overhead of having to maintain and sync messages across multiple nodes.
...
Build functionality at the node-level to combat spam using methods such as:
FIO Address reputation
Allow recipients to flag messages as spam
Rate-limiting
See related discussion regarding Request for Signature.