Start work on preparation for ShopSync over HTTP

[scmcgowen]

This PR adds specifications for doing ShopSync over HTTP as well as some convenience features for online shops, whether they be online-only or just have an online option

[PatriikPlays]

Will we just send ShopSync over HTTP to all ShopSync receivers manually?
Also, if not already planned, I think there should be a specification for the format to send, POST with Content-Type: application/json seems reasonable.

[scmcgowen]

Primarily, it will go to shopsync.herrkatze.com, but anyone can host their own http receiver. and yes, it will be application/json as a post request. Radon will have a list of receivers to send to, and the reference implementation that I run will have a websocket interface to receive shopsync packets from my server.

[slimit75]

Please forgive me if I'm being ignorant (I'm not on the new MC server and I forgot to unsubscribe from notifications 💀), but what is the point? It seems to add more complexity and relies on shop software being updated to point to new centralized receivers, which could be difficult for people who are just starting out and are setting up their own receivers.

It seems to go against what I had thought the original point of the spec was - anyone can broadcast their shops data to anyone listening. Stores that only function online can easily have a ShopSync feed set up that broadcasts over the current in-game-based system on a random (otherwise unused and easy to get) computer.

That being said, if you still wanted to do this, it would make more sense to have users of the standard pull a list of all of the receivers from one json file that could easily be maintained in this repository and pointed to by a raw GitHub link. It's not ideal, because it would still be needlessly centralized, but it has been done before. An online flight sim multiplayer network takes this approach, and while they've since removed most of the server entries and replaced them with "Automatic", you can still see how their file is structured here.

[scmcgowen]

On That server, Ender modems are going to be nerfed, which makes shopsync less usable. ShopSync over HTTP is planned to alleviate that by using HTTP. Modem-based ShopSync is still valid. I could add a standard list of known receivers though, and people could PR into it.

ShopSync over HTTP is not meant as a replacement to ShopSync over modem, but rather another option that exists alongside it. Shops can choose to support one, the other, or preferably both like Radon will

[slimit75]

I see, in that case I apologize. I still think having a lookup file is the best approach moving forward, preferably a file in this repository that people can PR into as you mentioned

[PatriikPlays]

Correct me if I'm wrong, but I think the point is for shops transmit over modem and HTTP, except for maybe shops that have no in-game presence. This brings up an interesting point though, should ShopSync messages contain some sort of standardized server id/name and a unique ID for the ShopSync message (this could be a timestamp + incrementing counter + message hash on the client sending the message)?

[scmcgowen]

I don't know what you mean by having them contain a server id/name? and a unique ID could be done with a timestamp and math.random() call? no need for it to be super complex. hell, I'd leave that up to implementation details as long as it won't generate the same id twice

[PatriikPlays]

I meant something like "reconnectedcc", "luminacc", etc. to make the single centralized server work with other servers. As for the unique ID being implementation dependent, that's probably a good idea.

[scmcgowen]

ah, yeah, I should add that parameter