Now that transfer packets exist, I'm thinking of a commercial server advertisement system that servers can make a profit with. It is a system where servers can pay to advertise themselves on other servers, and players will get transferred if they want to join it, or automatically (if the host server wants it). There should be five parties involved in each effective transfer (where a player is transferred due to an advertisement). For the sake of convenience, let's name these four parties with the fictional characters names in cryptology: Alice: the server that shows the advertisement (and the player initially joins it and sees the advertisement on it) Bob: the server that gets advertised (and the player eventually joins it) Steve: the player who sees the advertisement and gets transferred Peggy: the neutral host party for managing the ads and finance. Peggy should have a server (e.g. web server) that lets users manage their ads and money associated with this ad system. Minnie: the MCPE server also hosted by Peggy for managing the traffic for effective transfers. The system works like this: Bob creates an account in Peggy's server. Bob should "deposit" some money into this account by sending some money (e.g. through PayPal) to Peggy. This account's balance will be subtracted when an effective transfer takes place. Alice creates an account in Peggy's server. This account can have zero balance initially. This account's balance will be added when an effective transfer takes place. Steve (from IP address 1.2.3.4) joins Alice's server. Periodically, or through other means, Alice's server loads an advertisement message from Peggy passing the IP address 1.2.3.4#. Peggy returns an advertisement about Bob's server. This advertisement message is displayed to Steve. Steve is interested, so he runs a command* as specified in the advertisement message (e.g. "/ad bob"). Alice's server sends a request (e.g. HTTPS request) to Peggy's server to notify that a player named "Steve" from IP address 1.2.3.4 has accepted an advertisement about Bob's server. Alice's server transfers Steve to Minnie (at a fixed address). Minnie tells Peggy that Steve from IP address 1.2.3.4 (clients should still use the same IP address!) really got transferred. Peggy should do the financial stuff with Alice's and Bob's accounts after verifying that Alice sent a request in the past 10 seconds. Peggy tells Minnie to transfer Steve to 5.6.7.8:12345 (Bob's server address). * It is impossible to verify whether the player voluntarily accepted the advetisement and ran the command. Alice may force Steve to accept the advertisement. However, this does not seem to cause any problems. # This can prevent sending the same ad all the time. This will also make sure the system isn't abused by crazily accepting the same advertisement. What do you think about this system? Is it feasible? Are there any possible exploits? Note that I am not seriously requesting this system. I don't really want to use or manage this system; this thread is a pure theory. It would be nice to see a proof of concept though.
A possible exploit is that if you know a player (whom you aren't familiar with)'s both name and IP address, you can randomly send requests to Peggy so that you override other advertisers and gain profit yourself. This exploit can be prevented if Peggy randomly requests Alice to verify that Steve really joined her server by transferring Steve to Minnie and then immediately back. This may cause some distraction and worsen player experience though.
It's possible if the two servers trust each other. Okay, it's impossible. The LoginPacket can fetch you the domain the player used to join the server. That'll simplify some of your steps. PHP: var_dump(LoginPacket::$clientData["ServerAddress"]);
i do not get 8/Minnie, how does Minnie verify that? i have a proposal Bob: has a server, want to earn money by ads Alice: has a server, happy to pay in order to get players Steve: just generic server player(s) Carol: 3rd party hosting the ad system to seek profit 1. Steve would join bob's server 2. Bob's server would by any means fetch an ad from Carol and display it 3. Steve got interested in Alice's server so he does /XYZ command 4. Bob's server would transfer Steve to Carol's server (using slowtransfer etc to send the advertisement ID which is obtained via step2) 5. Carol's server would instantly transfer it back to Alice's server (using slowtransfer again to send the advertisement ID+ alice's shared secret with carol) 6. Alice's server would verify the secret, if it's valid it will send a confirm message back to Carol 7.Carol would deal with Bob's and Alice's credits appropriately additionally, to verify if player is "volunteered", they could be asked to give a token which is displayed with the ad, adding that in step 5 Which meant more delays and not very streamlined, but if you only want volunteered players and preventing server owners force transfer everyone, that would be the way to do it This wont stop servers that game it by means like "weekly quest: join 100 advertised server to get 32 diamonds" OR "You must join at least one advertised server weekly to be able to play on our servers" if Alice's server refuse to send a confirm message Carol could automatically temporarily turn it off if the rate exceed XYZ% as an misconfiguration detection system, or if it happens enough it could be flagged as abuse of system and get removed
If they trust, there doesn't need to be a financial medium for cooperation How does this help? Which step, and for what? An indeed good idea is to use it to transfer data like keys (e.g. the first 8 characters of Alice's signature for Steve's IP address is "123456ab", so players are transferred to 123456ab.minnie.com). This may help verifying, but you must have good control over the DNS. This reminds me of an idea to make servers like GitHub pages using this server address Minnie is hosted by Peggy, so Minnie and Peggy fully trust each other. Did you intentionally swap my two names What is it? Sending data can use other means than non-TransferPacket, if that's your meaning. (Using names in my OP) Also, if you mean a proxy, a proxy hosted by Minnie to Bob will mean that all data Steve shares with Bob will get intercepted by Minnie too. This is dangerous and impolite. Then Alice will always not confirm to prevent paying. Your explanation is very confusing. Could you keep using the names in my OP (I'm using names in my OP in the following) How does this token work? Any data sent by Steve are either transmitted through Alice or Bob, both of whom may modify the data to some extent (Bob wants to prevent paying, Alice wants to earn more). IDC. As long as the players eventually join Bob's server, I consider it a valid transfer.
i didnt consciously intentionally swap the names it just somehow happened https://github.com/Falkirks/SlowTransfer basically transferring the player WHILE sending additional information in carol's/3rd party/ad network organizer's server therefore both parties cannot do anything so after steve get transferred to this server it could just ask for token or just transfer it back where it needs to go (server paying for ad via the detail received when player was transferred here) (using OP's name) Alice: the server that shows the advertisement (and the player initially joins it and sees the advertisement on it) Bob: the server that gets advertised (and the player eventually joins it) Alice could try to send multiple transfer success request but it would need steve to be transferred to Carol's server as verifying purpose so that wont work Bob could try to not send confirmation request but Carol would know since it has just transferred Steve off his server to Bob's server
Yeah, something like SlowTransfer. But it should be handled by Peggy rather than Minnie, so not exactly SlowTransfer. If we really need to pass data to Minnie, it can be a simple identifier passed through, as I said, the subdomain of the first transfer. The data associated with the identifier can be passed to Peggy to be fetched by Minnie. That's why Minnie is needed. Bob doesn't have to do anything in the real effective transfer process. Instead of asking for a memorized token, just ask the player if he really wanted to go to Bob's server.
Let's see how this data flow can be exploited? Bob registering his server: submits an ad to Peggy to be reviewed (and don't let it contain misleading words that evades paying). For example, {"message": "Best PvP server with brooms, defend your castle by summoning skeletons!", "ip": "bob.com", "port": 1932} Alice registering her server: gets an account ID "deadb33f" from Peggy. When [email protected] joins Alice's server, Alice -> Peggy: "DISPLAY deadb33f Steve 1.2.3.4" (Peggy internally looks at the profile of 1.2.3.4, and finds that Bob's server is appropriate, so now it generates an "ad display ID" called "c0deface". Peggy -> Alice: "AD Steve 1.2.3.4 c0deface <ad data here>" Alice -> Steve: display the ad data So when Steve accepts this ad, Alice -> Peggy: "ADCLICK c0deface" Alice -> Steve: TransferPacket to c0deface.minnie.com Minnie <-> Peggy: internal data exchange about c0deface and internal execution Peggy/Minnie -> Bob: "ADSUCCESS Steve 1.2.3.4" (pure notification message, will not expect any response from Bob) Minnie -> Steve: transfer to bob.com
What's funny is I thought about a similar system a few mouthes ago and I faced a problem: Phars are can be decompressed and editable. So the src code is editable. So we can exploit the API to say "Hey, Steve has seen Bob's server ad ! Now give me my money." and Poggy, not knowing anything about Steve, will simply give the money to Alice owner while Steve will enjoy it's "ad free" experience. This is the "resonable hack". But what if the servers sends tons of requests with fake players and IPs? They would win a lot of money easily.
What if someone nulls the plugin? Anything in code can be modified. Unless someone hosts a database..!
that's why i propose my model having a 3rd party re transferring players of course, but we are just talking it in a very theoretical sense of abstractions... not literally doing it directly
What would be the point of using a third party? The plugin is on the server where the player is, not a 3rd party one. So if the player don't see an advertisement, why would he interact with it?
the server will fasttransfer the player to the 3rd party it's there to verify and prevent abuse, it's provided by the advertise system and as a requirement since it's now on the 3rd party server they can verify that no parties abused the system by having a middle man
From a professional perspective, even without open-source, people can still somehow hack your API just like what we do with MCPE. That's why they can't be paid unless they really get transferred. That's why Minnie is needed. To check if there is really such player. That's why I created this thread. The thread describes a system that is secure against such modifications, so even if you modify the code, the server side will still work as expected. Each time the player gets an ad, he can choose to accept or not. If he ignores the ad, nobody pays or gets paid. If he accepts the ad, he has to go to Minnie's server to verify that this ad is accepted. Did you seriously read my OP...
I had the exact same idea. Paid advertisements and transferring to advertised servers. I had too little time to make a move on it though, but it is indeed a great idea.
Ah ok. (The payment part wasnt specified in the OP. I thought the server gets money when the ad gets displayed).
There can also be an /angry command on Bob's server, which redirects the player back to angry.c0deface.minnie.com, and the player can do something to confirm that he didn't want to be transferred. Then Minnie can undo the financial reward for Alice, and probably reduce or cancel the deduction from Bob's account too. And if this happens too frequently, further penalize Alice.