Generic messaging layer

[jedmccaleb]

There are a lot of applications in the ecosystem that could benefit from a decentralized messaging layer. I think there should be some ecosystem standard for this for things like multi-sig coordination but it should be a layer above the core protocol.
#84 for example of people wanting this feature

[pselden]

I'm interested in hearing more about your thoughts on this, as well as any other use cases besides what was mentioned in #84 regarding multisig.

For the multisig coordination example, a decentralized messaging layer would be a good building block, but you would need another standardized protocol for the multisig messages on top of it or else we're back in the same boat as before.

Just trying to think through what it might look like to support multisig with it:

1. A user with Stellar Account "GA" attempts to submit a transaction that requires additional signatures.
2. The wallet that the user is using must detect that it requires additional signatures, and send out a specialized message through the messaging layer: { type: 'sigs_required', from: 'GA', xdr: '...' } -- maybe it also signs the message as well.
3. An interested party (StellarGuard) subscribes to messages for source "GA" and gets that "sigs_required" message. (Is the message ephemeral or can I query them?).
4. It stores the transaction and sends out the transaction email like usual.

Some outstanding questions off the top of my head:

1. If the data is not ephemeral, does it require an account to hold a minimum XLM to have a message? Seems like it couldn't if it's not part of the core protocol.
2. If the data is not ephemeral, why would I ever use ManageData instead of this?
3. If the data is ephemeral, what happens if I miss a message?
4. Would there ever be standard message types, or would it be up to the community to define them.

Sorry... that was a little stream-of-consciousness there... hope some of that made any sort of sense :)

[hmatejx]

I think such an ecosystem improvement would greatly extend possibilities and simplify multi-party protocols.

Specifically, one cool feature would be to make use of the ed25519-to-curve25519 "duality" for symmetric encryption (e.g. like I do in my Interstellar Whisper toy app).

However, the ledger capacity should be viewed as scarce and not as a place to store messages (e.g. NOT like I did in my toy app; shame on me).

Could IPFS be considered as a generic storage place, with IPFS hashshes stored on the ledger? Or is something new to be built, specifically for Stellar, which would not require an intersect with the ledger at all? I am really interested in the views of others here.

[MisterTicot]

@jedmccaleb

I did it:

• On-chain signature & transaction sharing (SEP): Add draft: Onchain Signatures & Transaction Sharing #158
• Reference implementation (complete): https://github.com/MisterTicot/js-stellar-oc-multisig
• Underlying generic messaging system: https://github.com/MisterTicot/js-stellar-oc-multisig/blob/master/src/messenger.js

stellar-oc-multisig contains a file called test/demo.js that demonstrate library functionalities. This is fully functional and full-featured multi-signature system can be built on top of it. I didn't made the messaging system into independent SEP and module due to the fact it could ends up overloading the ledger at current tx fee. I'm waiting for a feedback before going further.

The messaging system can handle up to 6Kb of data for a cost of 100.01 stroops.

[MisterTicot]

By the way should I release the messaging protocol standalone and write a SEP for it to be reviewed?

[hmatejx]

@MisterTicot

The issue that I see with using the ledger for exchanging data is that I can't think of many good reasons why such data should be made permanent. I believe ManageData is already covering that use case (and there are certainly valid use cases for that).

What would, for me personally at least, constitute a game-changer in developing dApps over Stellar, is if there would be some kind of an ephemeral messaging layer, for which data is kept in a "side-chain" for specific duration.

The duration would depend on the fee that you are willing to pay on the main chain in the "send data" transaction. The validity of the sent data would be be attested by the hash stored in the main chain, e.g. in the existing MEMO field.

From a developer perspective, if such a thing would exist, all I would need is a single SDK, and I can securely transact as well as communicate in a decentralized manner.

Moreover, the worst thing that I can imagine happening, in case you miss a message, is that you cannot proceed and you just have to retry. Am I missing something?

[MisterTicot]

@hmatejx

There are cases were it make sense to link data to account (data entries) and other were it make sense to link data to transactions (messages). For example if you are doing transparent accounting you may want to add an URL to your transactions, that link to some kind of description. It makes no sense to have that as a data entry

You comment on data being stored forever is indeed relevant. Naturaly, you would turn toward blockchain solution when immutability/permanency is what you looking for.

I'd answer on two levels:

First thing: not seeing application right now doesn't means there are none. Factually, blockchain technology is very new and there may be a broad range of applications we didn't imagined yet.

Of course this is not a sufficient answer. There are already things that might need it: voting system, transparent accounting, persistent games data, ...

Another good example is the decentralized signature sharing system I built: critical smart contracts may actually need a level of trust that only a blockchain solution can offer. In fact, I'll need it for a dApp I'm working on.

Your comment about side-chain is also very relevant: I'm always coding with side-chain in mind. Actually, the trustless multisig solution can run on side-chain even when coordinating main-net account. This messaging system is network-independ & is a generic solution that enrich Stellar technology, not only the main net.

I agree that a technology that allow to remove data at some point would be great, so we could achieve trustless database. However, I didn't heard about anybody working on it yet.

[hmatejx]

@MisterTicot, I fully agree with you that we cannot foresee all possible of future applications. I also find the message use-cases you list well justified.

But I nevertheless strongly root for developing an ephemeral messaging layer that would somehow "tether" to the DLT chain. I believe this should technically be possible. I also believe a proper fee vs. space*time setup could be designed to control overall size and bandwidth requirements.