A new "business" model

[Miguel Freitas]

Hi,

As some might have noticed from my recent posts, i'm advancing in implementing the twister crypto entirely into browser (javascript). This is not meant to replace the current native client approach, which will still be needed anyway and in some aspects is more secure, but it is meant for lowering the bar for people who want to use twister without installing anything (* not quite true... more below)

My idea is that both models should be supported. I'd like to share a few thoughts about how this may work, for discussion.

While running your own twister node adds storage and post replication capacity to the network, just accessing twister from a web browser would not... Then we might have a problem because the balance sheet of "added capacity" - "added users" has to work out.

What i envision is a model where a single public twister server, possibly based on digital-dreamer's proxy

https://github.com/digital-dreamer/twister-proxy

... would be able to serve multiple users. The server is, itself, a node in twister's p2p network so it basically acts like a gateway between p2p and https. 

Users using the public server would need to ask the server to join multiple torrents of who they want to follow. Therefore, more users => increased usage of the server's resources.

How many users a single server would be able to handle? I have no idea. This, however, helps with the balance sheet i've mentioned before. To grow in users, one may need to add more servers to his farm. More servers => more twister nodes => more capacity.

But then, who pays the bill at the end of the month?

When we run the native twister client in our computers, the cost is being implicitly paid by ourselves (electricity, broadband, hardware etc). But servers cost money to offer people a free service.

One possibility I have thought is that servers' owner may try to revenue from advertisement. While people running native twister would see ads from the blockchain miners, people accessing a given server would see ads from the server owner. I think that could be possibly a fair deal.

What if the server I use is sending too much ads to me? We may either limit this on the client, or you could just use another server. The beauty of having your private key into the browser is that the server is limited on what he may do to mess with your posts.

Can a misbehaving server hide some posts, or refuse to forward? Yes. But again, user would just change for a better provider. He is not attached to a particular server in any way, in fact, this is just a gateway point to access the p2p network. Any server would work just like the same.

There is also, of course, another security issue. For obvious reasons, we may never trust the server to send us the javascript code that does cryptography on our browser.

Therefore, the twister-html-crypto client would need to be securely delivered. Browsers extensions like in Chrome sound like the most natural solution to me, but another method might be possible...

So, that's basically it. As you may see, apart from technical issues a lot of other questions arise around this different "business" model. I don't have the answers and comments/ideas would be very appreciated.

regards,

Miguel

[Daan Wynen]

a really simple deployment could be just downloading a .zip of the twister-html repo and opening the main .html...?
I have no idea about extension development, but I figure that would be easier and, given js crypto is ready, might work (for now)
I like the idea of a "contract" between p2p server op and https client.
and for people who really don't want ads (me!) there is always self-hosting (with a really simple-to-setup docker) or just "pay for your service" kind of models.
but none of these would need to really affect twister-core *or* twister-html I guess.

[Miguel Freitas]

On Sat, Dec 20, 2014 at 8:17 PM, Daan Wynen <daan....@googlemail.com> wrote:

a really simple deployment could be just downloading a .zip of the twister-html repo and opening the main .html...?

I think so. There might be some issues with cross-domain security mechanisms of the browser (html from localhost trying to request json from another domain) that might need some thinking.

 

I have no idea about extension development, but I figure that would be easier and, given js crypto is ready, might work (for now)

I don't know the extension development details either. But i believe that, conceptually, it should work. Extension distribution from "google market / play" or similar may help ensuring that user is installing something that has been cryptographically signed by the author.

 

I like the idea of a "contract" between p2p server op and https client.
and for people who really don't want ads (me!) there is always self-hosting (with a really simple-to-setup docker) or just "pay for your service" kind of models.

Exactly.

 

but none of these would need to really affect twister-core *or* twister-html I guess.

Yes, you are right!

regards,

Miguel

 

[Сёма Мрачный]

I believe it is just an option. maybe useful in some cases but no more over. and which great benefits does it bring to user? what is a main point?

[Daan Wynen]

the benefit is that a user can use twister without setting up an own
server, even when their own connection does not permit true p2p.
I used to sneer at that kind of thing, but even the tiniest technical
obstacle will drive away a lot of non-technical users.
But when these same users just see the html interface they wouldn't even
see the difference, really.
Also, when you only start twisterd while you're running your home pc
(for a lot of people this is like an hour or two a day) then just
refreshing the blockchain and the new posts takes some time, during
which your timeline will look inconsistent, posts keep popping up
somehwere in the middle, you get notifications you already read etc etc.
This all goes away if twisterd runs (nearly) 24/7 (like, on a remote
machine).

As for the bandwidth thing:
I am currently running the twisterd on a remote server, not only because
my own system is not up 24/7 and thus starting twisterd would take time
and result in coldstart awkwardness, but also because the internet in my
own place is really crappy, so running p2p with many connections is not
even an option since it would immediately kill the connection.
A steady stream of rpc requests over https (or over ssh as I did
before) is not a problem though.
Like this my home connection does not have to handle all the p2p issues,
BUT my secret key s on the remote server which makes me feel a bit uneasy.
Sadly, crappy connections are not going to go away over night, so we
need to think about them.

[Miguel Freitas]

Daan,

On Sun, Dec 21, 2014 at 8:29 AM, Daan Wynen <daan....@googlemail.com> wrote:

Also, when you only start twisterd while you're running your home pc

(for a lot of people this is like an hour or two a day) then just
refreshing the blockchain and the new posts takes some time, during
which your timeline will look inconsistent, posts keep popping up
somehwere in the middle, you get notifications you already read etc etc.
This all goes away if twisterd runs (nearly) 24/7 (like, on a remote
machine).

You mentioned another important point: i'd like having the twister for windows installer automatically handling the mess of setting a "twisterd service". This way computers that stay on for a long time, or just get suspended, will have the node running for more time than UI is being used. The posts will be up-to-date already when you open the UI. This also helps for better user experience.

 

As for the bandwidth thing:
I am currently running the twisterd on a remote server, not only because
my own system is not up 24/7 and thus starting twisterd would take time
and result in coldstart awkwardness, but also because the internet in my
own place is really crappy, so running p2p with many connections is not
even an option since it would immediately kill the connection.
A steady stream of rpc requests over https (or over ssh as I did
before) is not a problem though.
Like this my home connection does not have to handle all the p2p issues,
BUT my secret key s on the remote server which makes me feel a bit uneasy.
Sadly, crappy connections are not going to go away over night, so we
need to think about them.

Another good usage scenario!

Not only you'd move your private key from the remote server to your own computer, but you would also be able to offer access to friends.

So whatever we do we may also try to make it easier for admins to create a couple of accounts. A private server. What do you think?

It is interesting to explore the most likely scenarios to focus the implementation efforts...

regards,

Miguel

 

[Сёма Мрачный]

yep, all of that is obvious, but I warn you to not reinvent Twitter. maybe federated, but of course less P2P-alike as I want it to see.

do we have no ways to improve protocol to meet the users expectations in part of more smooth and easy experience, no ways to build more convenient client?

// I do not want to be rude, but I suppose someone should to say it. and ten to one that I will run this proxy server which we are talking about, I really like Twister and I would like to help any user of it.

[Daan Wynen]

I see your point about making the system less decentralized with this.
But in a lot of scenarios it is technically infeasible to run any p2p
and still have a non-catastrophic user experience:
* corporate pc: constraints on p2p, but https is easy-peasy
* slow connection
* shaky and connection (even worse than shaky)
* stupid f*cking moron providers heuristically blocking/throttling
ports/protocols with no competitor available (sorry, had to let off
steam there...)
* running on a phone
* volume caps by providers (not really technical, and certainly
something I oppose, but something to consider, and qualifies for
infeasibility)

Even if we could work around all of this, the mere act of doing
*anything* else than opening a website will drive many people away.
This experience depends a tiny little bit on your social surroundings,
but I know loads of people actively using twitter/facebook who wouldn't
dream of *installing* anything to replace it.
Think about how successful gmail is. Loads of people don't even realize
there *are* such things as standalone email applications.
So, if we want to include these people, and personally I think we
should, then we need to take away *all* the barriers we can.

And think about it like that: when/if twister takes off and if running a
remote server provides benefit, eventually it will be implemented by
someone.
Might just as well incorporate it now, shape it sensibly and use it to
draw more people in the first place.

With all that being said, I think all we can do is encourage people to
run their own.
Like, on the download page, just have links and possibly more:
* sign up on one of these public servers (link list)
* run on your desktop
* start your own instance on $hostingprovider with this handy
one-click installation and provide the link to all your friends to use
this server!
* set up your own server from scratch (instructions)

my favourite is the third one :)

[Neil Haran]

Hi Miguel,

Can you email me at nhar...@gmail.com? I would really like to start helping develop Twister. Do you use QT Creator for your IDE? I'm on ubuntu and I'm a seasoned c++ developer, just mostly on Visual studio.

Thanks,
Neil

[Miguel Freitas]

Hi Neil,

Welcome! :-)

Yes, I use QT Creator and I'd highly recommend it for C++ development in linux.

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.

[chin...@mail2tor.com]

Hi,
Public nodes can be hosted by volunteers, just like blocks mined by
volunteers. If the way to setup a poblic node is easy enough( with just a
few clicks ), every P2P fan would setup one on his/her own computer.
What's more, public nodes hosted by volunteers are more dfficult to block
by gov firewall, when twister has dynamic DNS support. There are many
free domains on free dynamic DNS service, such as freedns.afraid.org

Regards,
@chinanet

[Julian Steinwachs]

Hi,

I total agree. Just my remarks to this:

To maintain meta-data security when using untrustable p2p-proxies the (html-)client needs to use at least 2 servers at the same time. One "outlet" server to which it announces the torrents it wants to follow, but to which it can stay anonymous. And an "inlet" server through which you publish your posts because of which you are not anonymous. So the clients needs to be able to handle multiple api endpoints. Then more endpoints the clients use, the better the security gets.

Also, i think it would be very cool to have a loose public pool of servers where everyone can make his server usable by non-selfhosting users. These servers could then be benchmarked in terms of uptime and responsiveness on a site like http://podupti.me that does the same for diaspora. Upon registration the client would then automatically chose some with good benchmarks for the user. Such a pool could also help to fairly distribute donation money. The Diaspora federation solely runs on donations. The cool thing about the pool of twister servers, however, is that you neither have to trust the admins nor rely on them to continue running the server, as you can switch them out at any point with minimal hassle.

Greetings

Tschaul

[Miguel Freitas]

Hi Julian,

Good points.

I'd also note that the benchmark of the servers could test not just their responsiveness, but also whether they are blocking some content or staying neutral as expected.

regards,

Miguel

[alan....@gmail.com]

Re: "Project: Use twister-html as a basis for a new Chrome App":

Instead of porting the native client entirely into JavaScript, why not use WebRTC to handle all the P2P connectivity? See, e.g., WebTorrent (source) or WebRTC-explorer source (WebRTC+DHT).

[Luca Matteis]

Because WebRTC isn't decentralized at all. It needs a website as a
rendezvous point to connect peers, which can only connect if the
website is there co "channel" them. In fact it's impossible it seems
to build a DHT on top of WebRTC:
https://github.com/feross/webtorrent/issues/288

WebRTC is good for bandwidth purposes, but not for decentralization.

[1776]

Hi,

I am curious if there is a status update on the "i'm advancing in implementing the twister crypto entirely into browser (javascript)" portion yet. 

Thanks

[Miguel Freitas]

On Mon, Oct 8, 2018 at 5:19 PM 1776 <cr1...@gmail.com> wrote:

Hi,

I am curious if there is a status update on the "i'm advancing in implementing the twister crypto entirely into browser (javascript)" portion yet. 

Thanks

The infrastructure is fully operational. This file does some (low level) test vector on crypto routines:

https://github.com/miguelfreitas/twister-html/blob/master/twister-crypto-test.html

AFAIK the only client using these JS crypto is twister-react:

https://github.com/Tschaul/twister-react

regards,

Miguel