purely web based twister

[Julian Steinwachs]

Hi all,

As a late follow up on miguels post and our discussion in december of
last year i wrapped up my ideas on the topic. Currently the only really
adopted way of using twister is running it on your desktop as a full
node. For twister to get to a significantly higher level of adoption i
think there needs to be an additional purely web based access to
twister. For that there needs to be some kind of pseudo-central
infrastructure as we discussed 6 month ago. I concretised these ideas to
a user story. To make this user story happen, quite some code would have
to be written and some servers would have to be hosted. It is meant as a
starting point for a discussion.



USER STORY


I. Sign Up

* User hears about Twister, goes to twister.net.co and clicks on "Start
twisting now"
* User is asked to install the twister-wallet browser-extension.
* After installation the user is redicted to a twister-signup-server site.
* User is asked to complete a CAPTCHA.
* User is asked to provide a username.
* If the username is available, the signup twister-signup-server site
requests the twister-wallet browser-extension to generate a new key pair
and yield the public key.
* The twister-signup-server site generates the newusertransation,
computes the POW and publishes the transaction to the blockchain
* After success the user gets redirected to a twister-web-client (or
gets to chose one of many)

II. Twister Client Setup

* The twister-web-client requests a list of accounts from the
twister-wallet browser-extension.
* After confirmation by the user the twister-web-client is given access
to the list of wallet accounts.
* The twister-web-client requests a public twister-proxy address from a
twister-proxy-directory server. (Or the user provides a custom proxy)
* The set up twister-proxy joins the torrent of the user

III. Discovering Other Users

* Through the twister-proxy the twister-web-client provides the
functionality to search and browse the profiles and timelines of other
twister users.

IV. Following Users

* The twister-web-client composes a new following post given the users
request.
* The twister-web-client requests a signature for the following post
from the twister-wallet browser-extension, which may have to be
confirmed by the user.
* The twister-web-client publishes the new following post through the
twister-proxy and tells it to join the torrent of the followed twister user

V. Twisting

* The twister-web-client composes the raw posts (status, retwist, reply,
mention and hashtag) given the users input.
* The twister-web-client requests signatures for the posts from the
twister-wallet browser-extension, which may have to be confirmed by the
user.
* The twister-web-client publishes the new posts through the
twister-proxy on the dht as well as on the users torrent.

VI. Direct Messages

* The twister-web-client composes the raw (unencrypted) direct message
given the users input.
* It requests the encryption for the direct message from the
twister-wallet browser-extension, which may have to be confirmed by the
user.
* The twister-web-client publishes the encrpyted direct message on the
users torrent through the twister-proxy.


GLOSSARY


* twister-wallet browser-extension:

Allready existing for PGP (https://github.com/mailvelope/mailvelope
licensed under AGPL). A lot of the code should be adoptable for twister.
The wallet stores the private keys of the users and signs and encrpyts
posts on behalf of the user. Web sites send method calls
(generate/list/sign/encrpyt/decrypt) over "ports" (see mailvelope). The
wallet has user configurable access restrictions per web site. The
wallet handles users private key information. Therefore a high level of
trust in the code is required. This piece of software is the biggest
missing part in the chain.


* twister-signup-server:

Not yet existing. Maybe built with node.js on top of a local twisterd.
Additionally to a CAPTCHA it should have a strict rate limiting per IP.
Should have somewhat beefy hardware to handle the signup (POW) quickly.
Does not store any private key information. The required trust is
therefore very low.


* twister-proxy:

Existing at https://github.com/digital-dreamer/twister-proxy . A public
twisterd instance accessible over https. Does not store any private key
information. The required trust is therefore very low.


* twister-proxy-directory:

Not yet existing. Stores a list of twister-proxy adresses and regularly
bechmarks them by running random dht calls. Has both an API and an
frontend to access the list and benchmarks as well as to add new
proxies. No user information is exchanged. Therefore no trust is required.


* twister-web-client:

Similar to current twister-html, but relies on a remote twister-proxy
server and a local twister-wallet browser-extension. It only sends out
post that are encpryted/signed by the wallet. The client does not get in
contact with private key information, but with unencrypted messages
(depending on user configured access level). A certain level of trust is
therefore required.


Greetings,

Tschaul

[Miguel Freitas]

Hi Julian,

Thank you very much for giving some thought to this!

This idea of having a twister-wallet browser extension separate from
the twister-web-client is interesting. I've never thought of that.

To be frank, i wouldn't personally code it that way from the start.
I'd prefer to simplify by having the wallet + web-client merged in a
single extension and then possibly evolve to separate things in future
as needed. But hey, that shouldn't prevent anyone from trying it
though ;-)

I also don't quite get the benefit of the signup-server. One advantage
of computing the registration POW on the client is that it will get
propagated to the other nodes faster than an attacker is able to forge
another registration with the same username. twisterd already supports
'sendrawtransaction' for this purpose in a public proxy server.

What i'd originally envisioned is that web-client should be able to
connect to a few proxies at the same time. This permit interesting
things: by checking the posts' signatures, checking for missing posts
or excessive spaming, the web-client would be able to remove rogue
public proxies from its lists.

regards,

Miguel

> --
> You received this message because you are subscribed to the Google Groups
> "twister-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to twister-dev...@googlegroups.com.
> To post to this group, send email to twist...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Julian Steinwachs]

On 22/06/15 01:28, Miguel Freitas wrote:
> Hi Julian,
>
> Thank you very much for giving some thought to this!
>
> This idea of having a twister-wallet browser extension separate from
> the twister-web-client is interesting. I've never thought of that.
>
> To be frank, i wouldn't personally code it that way from the start.
> I'd prefer to simplify by having the wallet + web-client merged in a
> single extension and then possibly evolve to separate things in future
> as needed. But hey, that shouldn't prevent anyone from trying it
> though ;-)

I think separating the wallet from the client makes a lot of sense. In
terms of securtiy, because the crypto code doesn't need to change very
often so it can sit in its own repository. And also for twister as a
platform, because the extension-wallet could be used by any site to
embed twister functionality like a follow button for example. I think
the most important question is how to attract developers. That is why i
started twister-lib-js, to make it easier to get started. If all the key
and proxy infrastructure would also be just an script include away, that
would be very neat i think.

>
> I also don't quite get the benefit of the signup-server. One advantage
> of computing the registration POW on the client is that it will get
> propagated to the other nodes faster than an attacker is able to forge
> another registration with the same username. twisterd already supports
> 'sendrawtransaction' for this purpose in a public proxy server.

The only benefit is to reduce the time the user has to wait for the POW.
I cant imagine that it is very doable to compute the POW in the browser
e.g. for smartphones and lower end hardware. That is why i think it
would be nice to have a server that does that for the user after a
successful CAPTCHA.

>
> What i'd originally envisioned is that web-client should be able to
> connect to a few proxies at the same time. This permit interesting
> things: by checking the posts' signatures, checking for missing posts
> or excessive spaming, the web-client would be able to remove rogue
> public proxies from its lists.

That would be cool indeed.