Question about open sourcing

ID:1975798
 
Nov 1 2015, 4:36 pm
(See the best response by Lummox JR.)
If I make a game of mine open-source, is there anything the BYOND administration can do to enforce a rule along the lines of "Only to be hosted at x"?

I'll probably still release it either way, but it'd be nice to be able to enforce the rule to keep the game's community centralized.
Nov 1 2015, 4:54 pm
Best response
Rushnut wrote:
If I make a game of mine open-source, is there anything the BYOND administration can do to enforce a rule along the lines of "Only to be hosted at x"?

No. There's nothing built into the hub that would allow for such a thing.

I don't know if you need to worry too much about centralization. It will start out naturally fairly centralized, and if it decentralizes significantly it'll be as a result of runaway success like SS13 had. So win-win.
Nov 1 2015, 4:55 pm
Well, you can take down hubs. That was what I was thinking along the lines of.

E- Alright fair enough, thanks for letting me know.
Nov 1 2015, 4:59 pm
If they all appeared on the parent hub entry, as they do for SS13, then taking down the hub entry isn't an option. If they branched out into their own hub entries, that'd be a rip-like situation which we don't get involved with.
Nov 2 2015, 8:44 am
I had always dreamed of being able to have a central server that distributed the current hub password if a server was authorized to broadcast through that hub.

I think the only problem I encountered was that I'd like to be able to rotate the hub password daily or something to that effect so that sniffing the current hub password wasn't such a big deal, I'd just have the central server change it and re-distribute as necessary.
Nov 2 2015, 5:23 pm
Couldn't you potentially create a 2FA system using an API?
Every time the game attempts to host, have the host enter the API key, and verify if it's allowed?
https://www.authy.com/developers/
Nov 2 2015, 8:55 pm
Or you could have a list of all the people who are allowed to host and if they can't the server shuts itself down.

Having keys changing constantly can cause alot of hassle imo and what if someone misplaces their key or accidentally deletes it or forgets it.
Nov 2 2015, 9:01 pm
In response to Colesprite
Colesprite wrote:
Or you could have a list of all the people who are allowed to host and if they can't the server shuts itself down.

Having keys changing constantly can cause alot of hassle imo and what if someone misplaces their key or accidentally deletes it or forgets it.

Even if you were to reach out to an external server for this information, that can easily be spoofed with a routing rule. There's several demos of this approach, and demos on how to defeat such an approach.
Nov 2 2015, 9:18 pm (Edited on Nov 2 2015, 11:25 pm)
In response to Audeuro
Audeuro wrote:
I had always dreamed of being able to have a central server that distributed the current hub password if a server was authorized to broadcast through that hub.

I think the only problem I encountered was that I'd like to be able to rotate the hub password daily or something to that effect so that sniffing the current hub password wasn't such a big deal, I'd just have the central server change it and re-distribute as necessary.

You could probably use an asymmetric cryptographic system to implement this. The server and user each have two pairs of keys: Message keys, which are their public/private pair to send/receive information, and Identity keys are the public/private pair to verify identity. The public key for the Messsage keys would be for encryption, and the private key for decryption; the public key for the Identity keys would be for encryption, while the private key for decryption. Then the protocol would be as follows for Alice to message the Server, where Me and Md are the Message encryption and decryption keys, and Ie and Id are the Identity encryption and decryption keys:

  1. Alice decides on her message m. Presumably, this would be dictated by the protocol.
  2. Alice encrypts her message as Ie(m). Since she's the only one who can encypt it with her key, it verifies her identity.
  3. Alice adds her name to the message, to indicate how to decrypt the message (i.e., whose public identity key Id to look up). So now we have Alice+Ie(m).
  4. Alice now encrypts the message again as Me(Alice+Ie(m)). This secures the message, because the server is the only one who can decrypt it.
  5. The server recieves the message Me(Alice+Ie(m)) and decrypts it using Md, which only it knows.
  6. The server reads the metadata and sees the message is allegedly from Alice. It looks up Alice's last known Identity key Id and tries to decrypt the remaining part of the message Ie(m) with it.
  7. Having successfully decrypted the message m, the Server is now sure (unless Alice's key is compromised) it's actually from Alice. It sees Alice is requesting the new hub password, so it packages the message using this same protocol and sends it out.
  8. Alice, having received the message and verified its integrity, now has the hub password.