Let insert coin tokens have a credit state

[wizzomafizzo]

It would be fun if insert coin tokens supported having an amount of available credit stored on the token itself, and this credit was spent each tap

For example **input.coinp1:2,20

Each time the token is read, it presses the insert coin button 2 times, and decrements the 20 by 1. During this process, the following would be written to the card:

**Input.coinp1:2,19

This would be an optional argument. Once the credits are spent, the token will no longer press the insert coin key

I think the actions should happen in this sequence: command is read and validated, new value is written to token, insert coin key is pressed. This way the user won't have feedback they can remove the card until the write is complete

The current method of writing will need to be completely overhauled for this to work, currently it must shut down the service and restart it, which won't work at all. I'm hoping this will be easier to implement now that I've refactored the poll reader process. We also need to keep in mind if it is a chained commanded when rewriting

Once writing during the main poll loop works, we could also look at an action queue, so that reading a token can affect the next read token. For example to have a token which add credits to the next read token. Or, unrelated to this, a token which would write the current playing game to the next read token

[wizzomafizzo]

Also would be good to implement the write validation

[asturur]

What feature will this support? Without a password or lightweight encryption of the value, even just trivial, this is no good for anyone that wants to limit play to someone else that may not want the play limited

[sigboe]

I have thought about this, without a central web server, or user defined encryption, this can't be used for an actual production environment

[asturur]

maybe the feature is:

• get a configured api in the settings
• on read api:token send the token up
• api returns next command and next token
• write the new token

and this production environment disable the commands that wants to gate with the secret tokens with a blocklist

[asturur]

so in my card i have written 'api:shdhdjdnwjshhhaass', when i scan it i send the string to my own api. the api returns: 'add 1 credit', next token 'shefsjhhhssdaaa'. And we write on the card 'shefsjhhhssdaaa' and after confirming write we execute 'add 1 credit'

[wizzomafizzo]

Oh this is just a silly idea for fun and to test the write feature. I was imagining it maybe some sort of challenge thing with a friend you each get a loaded coin card and only get so many continues each

I agree the only way to create a secure version of this is with a central server

I am not really interested in implementing the infrastructure to do that. But I'm opening to supporting such a feature to work in a more generic way. Maybe it could be as simple as allowing the http.get and http.post to actually parse the response and execute them? So you have a token with **http.get:http://10.0.0.2:1234/add_coin?id=ff410832-de70-4e02-b21b-6522e3405560,

The server is pinged, sends back the action to do instead, how about we make it the same format as the tokens. So the server response if there's still credits is **input.coinp1:1 which is executed by TapTo. And done, simple as that. We only need to add support to parse and execute server responses

I can imagine you don't always want this behaviour. Maybe there's an additional command like http.parse which will execute the result of a previous http command in the chain. I dunno, probably still needs some thought

Hell, what if we supported encrypting the contents of cards as well? Nothing major, just allow adding an encryption key to the ini that is used for reads (if it looks encrypted) and writes

EDIT: I just noticed you mention the encryption already haha

[sigboe]

I was thinking about the encryption thing, without a central server, the malicious user could just copy a card with lots of coins, use the coins, and write it back.

Let's assume we don't want to make this a paid(cheap) service, where we host the central server.

But lets say for a central server... may just be an sql database!

Also lets say we assume the mister is secured. If someone actually wants to run this, we have a guide, that helps the user somewhat secure the MiSTer. We can talk later what a secured MiSTer looks like.

We decide what we want to have on the card for information. Minimum, it's just a username. We encrypt it with gnu pgp, and write it to the card. Username is maybe serial number of the card + a generated card.

The user scan's the card, it is decrypted with the public key that is on the MiSTer.

Interact with the pasworded sql server, adds coin if there are coins that has not expired (coins expiring is optional). Adds a coin to the game, and removes one from the server.

fronted to add coins to the SQL server written in bash with a dialog UI... wait no just kidding (or am I?)

[asturur]

Guys the solution is the one i mentioned with the tokens

[wizzomafizzo]

Guys the solution is the one i mentioned with the tokens

I guess what I don't understand is what is the purpose of writing back any data to the token if you're already dealing with a central server. Why not just put effectively a username on the token that never changes, and handle all the state and response back on the server? Is there something I missed with the idea you're saying?

[wizzomafizzo]

Oh I just got it. To avoid copying the card right, it's a rolling token