digital-dreamer/twister-proxy

RPC proxy for running a public server for the Twister P2P microblogging platform.

twister-proxy's Issues

Multiple hosts / load balancing

Hi,

I'm running twister-proxy over at https://twister-proxy.tschaul.com/index.html and its working great so far, thank you. My client is still missing some features, but its getting there.

On a longer timescale i'm thinking about scaling the whole thing. It would be easy to just set up multiple proxies, which would mean to scale with the users. But from the technical side it would make much more sense to scale with the following/torrents because they mostly overlap and in the end otherwise all of the proxies would join the same torrents and make a lot of useless traffic with each other. Also from the usability side it would be better, because the proxy can grow and shrink without the consumer of the proxy (i.e. the client) noticing as it always uses the same endpoint. This also makes it less risky to have unreliable servers in the mix. Theoretically all running normally running twisterd instances could (maybe somday) announce themselves to such a proxy to help it out while they are online.

What i'm thinking about is to have one twister-proxy instance manage mulitple (N) twisterd instances. And by some scheme these would divide up the followings of the users with some overlap for reliability. The twister-proxy would than redirect the incoming api calls to one of the correct twisterd instances respectively. Some of the calls (e.g. getlasthaves) would need to get split up, send to multiple instances and rejoined. But overall i think it should be doable.

Do you say that something like this is in the scope of this project, or would you rather keep it simple?

error in the script

NodeJS is complaining there's an error in your script when I try to run it:

events.js:141
throw er; // Unhandled 'error' event
^

Error: listen EACCES 0.0.0.0:80
at Object.exports._errnoException (util.js:837:11)
at exports._exceptionWithHostPort (util.js:860:20)
at Server._listen2 (net.js:1218:19)
at listen (net.js:1267:10)
at Server.listen (net.js:1363:5)
at Object. (C:\Users\Adam24\AppData\Roaming\Twister\twister-proxy
-master\twister-proxy.js:209:24)
at Module._compile (module.js:434:26)
at Object.Module._extensions..js (module.js:452:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)

Buffer() is deprecated due to security and usability issues

[DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

autofollow most requested users

Hi,

At https://github.com/Tschaul/LibTwister i'm building an javascript library that works together with this proxy to enable access to the twister network (right now its read only and incomplete). When i query my own timeline of the last 24h over this it takes up to 1min until all the information is pulled down (including avatar and profiles, proxy sitting in a data center). While this is much better than starting up twisterd locally, which takes multiple minutes until it joined all the swarms, 1min boot-up-time is far from perfect.

Partly this can be optimized on the client side. But the best improvement i think would be if the proxy would keep statistics on which users posts are request most often and let twisterd join those swarms ("follow" as "guest"). The client could then check through the "torrentstatus" method whether the proxy has joined a given swarm and then use "getposts" to query posts.

Right now these methods ("follow", "torrentstatus" and "getposts") are not available in public-server-mode. So they would have to be opened up. But i don't really know what the public-server-mode is good for because twister-proxy is already limiting the API-access and twisterd only accepts calls from localhost (if set so).

What do you think? I will play around a bit and let u know then.

long polling

Hi,

Right now the twister client sends out an rpcrequest every second ~95% of which have an empty result. When twisterd is running locally this is not much of a problem. But when used remotely, this can strain resources. I just had the idea that twister-proxy could detect responses with empty results, redo these repeatedly on behalf of the user while keeping the connection alive, and only pipe the answer down to the client if the result is not empty. This would then feel like long polling for the client.

Greetings
Tschaul

Error

events.js:72
throw er; // Unhandled 'error' event
^
Error: listen EACCES
at errnoException (net.js:905:11)
at Server._listen2 (net.js:1024:19)
at listen (net.js:1065:10)
at Server.listen (net.js:1139:5)
at Object. (/Users/Shift/twister-proxy/twister-proxy.js:201:24)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)

EFF Certbot?

Has anyone attempt to generate the SSL with the EFF's certbot? (https://certbot.eff.org)

Figured I'd ask and see. If I am successful with it, I'll update this.

401 Unauthorized.

I get 401 Unauthorized.

Twister.conf:
rpcuser=user
rpcpassword=pwd
rpcallowip=127.0.0.1
daemon=1

twister-proxy conf:
"RPC":
{
"host": "127.0.0.1",
"port": 28332,
"user": "user",
"password": "pwd"
},