ivangabriele
commented
6 years ago Firstly, I suggest that we focus on a working solution that will only work with public messages sent via Twitter as there will already be many difficulties to come through in that context.
Secondly, I suggest that we start the project either on a separate branch on this repository, or as a brand new one. A brand new would be more likely, since even it looks similar to SocialPay, SocialPay is a private solution while this proposal concerns a global one with no need for any recipient or user to install anything else than an ECA wallet.
We could in fact even call it UniversalPay ;)
What can't be done ?
Let's start with what need to be avoided from the start:
- Twitter will ban, sooner or later, any API application using their API to exchange payments.
- Twitter will ban, sooner or later, any account "registering" payments transactions.
- Twitter will ban, sooner or later, any non-legit Search Engine "bot" regularly scraping their website if this bot has one or multiple common IP addresses.
This takes away 3 possibilities:
- We can't use their API via a registered application to look for
!paystrings whether via a global search or user accounts search. This is without taking into account the fact that the throttle limit is very limited. - We can't create an ECA payment account as listener for ECA transactions (in the case somebody would have to do a
@PayECA @Somebody 500for example) as this account would be banned. - We can't, on the long term, use a server bot to simply scrap their search URL (i.e.
https://twitter.com/search?f=tweets&vertical=default&q=%21pay&src=typd) URL since this server IP would simply be banned at some point.
What is a blocker ?
We can't have an absolute safe access to our users wallets.
What is important ?
In order to have something really easy to use for users, they need to do not require any other action than linking their account within their wallet app so that we can associate an address with their Twitter ID.
What is a possible solution ?
First we should find a way to use our desktop wallets as a cloud able to scrap Twitter public search URL and / or the registered accounts. The server bot would then only receive transaction "orders" that would be double checked (to avoid any malicious incoming order) and then sign and broadcast the transactions.
Secondly, about the ability to "safely" access a remote wallet in order to sign and broadcast a transaction, the best way is to in fact reserve a reasonably tiny part of the wallet for this kind of transactions. We can take advantage of the HD wallet EIP in order to achieve that: indeed we could automatically generate a third degree derived address for which the private key would be shared with the server. This exchange must be done via a three parties SSL certificate to avoid any man-in-the-middle attack. This third degree address won't be revealed to the end user and he will be able to choose how much he can "reserve" on it with a reasonably low limit, left to be decided.
Request For Comments - Electra Social Pay
The purpose of this document is to come up with a reviewed and collectively agreed design to implement a Payment System based on ECA and integrated with relevant social media (e.g. twitter, facebook, etc).
Electra Social Pay aims to be a simple, quick and reliable way of exchanging micro payments between members of the ECA community.
A use case scenario
Because there is no specification to adhere to, let's try to come up with a couple of examples of how we envision a ECA Social Payment transaction to happen. In the youtube video there is an interesting example of a prototype already realised here at Electra.
A ECA user can trigger a payment via twitter, updating their own status with:
!pay @recipient XThis is a simple and yet powerful enough example of how Electra Social Pay should work.
Requirements
In this paragraph we will try to list what could be a simple subset of requirements on which to base Electra Social Payment engine.
Simplicity
Because we want to reach out the broadest possible audience, it is necessary to make ECA Social Payment easy to run. Users should not have to download any further software (wallets included!) but only register on a Social Payment platform, top up their ECA Social Payment wallet and start sending micro payments on the network.
Speed
Another fundamental requirement is speed. Fortunately, this is already intrinsically embedded in ECA.
Security
The last, but definitely most important aspect is security. Because we're dealing with users funds, it is required to prevent malicious people to compromise the system security and complete payments on the behalf of ECA users. It would be ideal to structure the ECA Social Payment request into two main parts:
There are multiple (some of which very fancy like a mobile push notifications!) ways of implementing in near-real-time a confirmation process, with a link sent via text message or email being the simplest two.
High Level Solution
In this chapter we will describe a few extensible key components that will compose ECA Social Pay.
ECA Social Payment System
The idea is to create a new platform, possibly hosted in the cloud and developed and maintained by ECA Engineers. ECA users should be able to signup via email, get assigned a wallet id, top it up with some ECAs, register their twitter handle, and start to send payments to other users.
The key components are:
In the image below a wonderful diagram hand made of a possible ECA Social Pay architecture.
Here there are a few user interactions with ECA Social Pay
Feel free to comment or ask questions, once an initial discussion phase is complete and agreed, a more detailed technical resources will be added to this thread.