Consider using freedom.js

[willscott]

I noticed you starred http://github.com/freedomjs/freedom and it seems like it would be pretty well aligned to what you're trying to do here. We're trying to make it easier to build JS apps that interact with existing social networks rather than having your your own server, while still doing security well.

If this is interesting, I'm happy to answer questions and so forth :+1:

[RainaBatwing]

I don't feel that approach can work at scale. As soon as it starts consuming a noticeable amount of resources from the host/victim social network service, they'll be compelled to shut down the project using your library because american law enforcement will not like their legal wiretaps being denied and the network's own bookkeepers will not like paying to run a competitors backend, when it generates no revenue for the company.

The only good argument I've been able to think of against using a purely decentralised p2p approach is that some mobile apps may have a bit of a difficult time with it. For a local mesh of friends of significant size some friends will leave computers on with desktop app versions running, so there shouldn't be downtime, and at worse it would just queue for delivery to the mesh until someone becomes available, via IP or potentially bluetooth or other PAN-type networks when Telehash adds support for those in the future.

I'm sure freedom.js is a viable solution if your goal is to have a small private group with yourself and some dev friends, to experiment, try interesting user interfaces, or whatever you like really, but if your goal is to affect social change by appealing to a larger audience, you can't have your core technology depend on a service run by your competitor.

[willscott]

I don't think we're actually aiming for different things, just talking about it in different ways :smiley: We have a split concept between 'social networks' which are meant to be asynchronous and used for rendezvous and discovery, and 'transport' which is used for longer, higher-bandwidth connections. The system will help setup and maintain a direct WebRTC connection between users for that persistent connection.

We're also experimenting with having some users be able to act as community nodes for more discoverability and uptime.

I think the deeper thing we're trying to say is that if you write your application logic in javascript with a declarative interface, then it can run not only across browsers, but also on node.js servers and with replicated storage, so the distributed systems problem can be separated somewhat from the specific app.

[RainaBatwing]

I don't see any reason for their to be a distinction between synchronous and asynchronous communication. I'm disinterested in technology like radiatus which appears to run over TCP. TCP is not a good technology for p2p networking as general users are unfamiliar and often unable to configure network equipment to allow incoming TCP traffic to their house, and UPnP/NAT-PMP are not widespread, especially on public infrastructure like cellular networks and free wifi hotspots. Centralisation weakens the resilience of the network and complicates mesh layout and information routing decisions. The relatively small scale of a private social network akin to facebook means supernodes are unnecessary.

Party wont be running from a web server in the immediate future. There is no technology currently which allows this to happen in a secure way, and running from a server requires someone to foot the bill, which requires either advertising or paying users, both of which are repugnant and inequitable. The only bill internet users reliably pay is their internet access bill. It is a resource we can use without any issue. By operating as a mesh, with no supernodes, no community nodes, no offline caching servers, everyone contributes a fair amount of their computing and network resources to the operating cost of the network on the basis of their usage of the network. There is no imbalance of power in this case. I firmly believe Diaspora has failed to be adopted by nearly everyone because of the power imbalance they created by centralising through the use of servers.

Imagine for a second, with all the creepy lecherous male geeks on the web, how much female internet users do not want to use services run generously by random servergeeks. Imagine the subtle sense of debt owed to potential creeps. The possibility that one of those server dudes could target your IP specifically and serve you an insecure version of the app, spy on your content, or threaten to remove it if you do something they consider distasteful, like call them out for bad behaviour. Diaspora and "community node" designs like that are disempowering and repulsive to me. Nobody can have special privilege or power on an ethically built computer network.

Telehash V2 already provides portable addressing which seamlessly shifts between network interfaces (wifi, cellular, potentially bluetooth), public-key encrypted message delivery, both unreliable and reliable (emulating TCP), and distributed hole punching creating the illusion that NATs and firewalls do not exist. I'm struggling to imagine what else Party would realistically need. Telehash can even run over WebRTC, though I do not intend to use that feature as Party is not a webapp and does not run in browsers.

The internet was designed for P2P. There is no reason to centralise any of this. I don't even need a central server for software updates. Everything can be totally distributed. At private social network scale, none of this is even conceptually difficult. Nonoptimal solutions are totally fine. There is no reason to compromise and emulate the failed client-server models of capitalist endeavours. Not even a bit.

I guess this issue has turned in to a bit of a manifesto. Oh well. Hopefully you understand my goals and perspectives a little better now?