Robbert Banks
My feedback
1 result found
-
15 votes
An error occurred while saving the comment
Robbert Banks
1 result found
Robbert Banks
supported this idea
·
I think this is close enough to my idea that I'll jump on, looking for a matchmaking and relay servers service. easiest example is game dev, but it extends to any user hosted service that is short lived and wants to talk to other services like it, whilst also being fully distributed.
will note, my concern with the above is the relay cant be fully removed from the chain completely as that would mean the both parties have the IP address of the other, which could be a security concern. That said at that level of relay it would fall under would be a similar process to a vpn so would be similar overhead to the free service.
my current usecase:
browser game want multiplayer but don't want to host the server. since its not an mmo its like hang man. Im imagining the service would use passwords/UUIDs or similar to communicate intent to connect the two instances of service, or a user can set up a channel_password/UUIDs to subscribe to and post to a wider group of instances. the latter would allow for match making and discovery but also be opt in so you can as a client/server not request to be notified and so not receive any data from the wider channel_id.
on a networking level the requests would all go to a proton ip which would use the channel_id or password to route it accordingly in the same way a vpn or proxy would.
The communications would have to use something like URL parameters to pass the UUID/channel_id so proton knows who to give it to, doing so in a way it is invisible to the receiver wouldn't be impossible. The client then can determine if it cares based on the auth/password in the header. This would mean it was still end to end and the UUID/channel_id can be per session so that reduces any attack vectors.
I see this as a service proton can offer to create a way for fully distributed adhoc server hosting from non-static ip or data centre servers. I imagine this becoming a way to de-centrally host applications with smaller interaction numbers and not require the same one processing server to rule them all. Further i think proton fits this specifically as the ethos around security lends itself to being the service to trust with the job of brokering the connection.