Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic messaging layer #143

Open
jedmccaleb opened this issue Aug 3, 2018 · 7 comments
Open

Generic messaging layer #143

jedmccaleb opened this issue Aug 3, 2018 · 7 comments
Labels
help wanted Open especially for those who want to write a CAP/SEP! needs draft This an issue that has no corresponding draft, and as such has not entered the CAP/SEP process. SEP Represents an issue that requires a SEP.

Comments

@jedmccaleb
Copy link
Contributor

jedmccaleb commented Aug 3, 2018

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
Copy link
Contributor

pselden commented Aug 13, 2018

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
Copy link

hmatejx commented Sep 12, 2018

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
Copy link
Contributor

@jedmccaleb

I did it:

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
Copy link
Contributor

MisterTicot commented Sep 23, 2018

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

@hmatejx
Copy link

hmatejx commented Jan 10, 2019

@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
Copy link
Contributor

@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
Copy link

hmatejx commented Jan 15, 2019

@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.

@theaeolianmachine theaeolianmachine added needs draft This an issue that has no corresponding draft, and as such has not entered the CAP/SEP process. help wanted Open especially for those who want to write a CAP/SEP! and removed incomplete labels Mar 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Open especially for those who want to write a CAP/SEP! needs draft This an issue that has no corresponding draft, and as such has not entered the CAP/SEP process. SEP Represents an issue that requires a SEP.
Projects
None yet
Development

No branches or pull requests

6 participants
@jedmccaleb @theaeolianmachine @pselden @hmatejx @MisterTicot and others