CRUD with UUID generation - need some direction

Developers Programs & Applications
1

I’m trying to make some basic CRUD functionality and I’ve cobbled together pieces of code from tutorials and repos, but basically I haven’t got a clue.

Could anybody provide any direction as to what I should do? I’d like to be able to have different entity definitions (Item, Monster, Rarity, Quest etc.) and each one of them has a UUID and then a list of other fields.

I’m not really sure how to structure it, but I started with Rarity which is just ID and Name, and wanted to get that working first before attempting any more.

Thanks!

3 Likes
2

Hey there.

Is it critical for you to use UUID instead of BigInteger?
You could create a state variable (something like GLOBAL_ID_COUNTER = 0) and increment it each time you provide a new ID for any entity.

You could implement UUID (all you need for it is just a 16 bytes of pseudo-random data, which I believe could be acquired from the msg object) but I don’t really see any reason for it.

1 Like
3

Hi - yes technically I could use an integer for the ID, if that value is hidden from the user and just used internally.

Our entities are semi-transparent to the user, so for instance, an Item could have ID 1, but it also has a “Resource ID” which is used by the players to look it up. So a player couldn’t go and look up everything by just passing in consecutive IDs, they’d need to know the actual UUID of that row.

For instance
1 Apple 39f72878scsb
2 Sword b9c8376434f

That would totally work, but yeah I wouldn’t want the players to find out every single item in the game by using a script. So yeah, I guess ID as an integer works but doesn’t solve the whole problem.

4

Blockchains are transparent by their nature. Your users WILL be able to use script to parse all your data anyway, unless you figure out a way how to encrypt sensitive data.

1 Like
5

Think of it as of some kind of advantage - nobody would ever pirate or break your game, because it is already open for everybody.

Onchain multiplayer games are hard. It is hard to reach real-time performance (I could only imagine some kind of p2p solution with eventual onchain synchronization), it is hard to implement a generic anti-cheat (for cheats like wallhack or aimbot, I mean) and it is hard to store sensitive data.

You can be the first team to reach this goal and create this new market.

6

Oh yeah, we’ve also got an advantage because the game literally cannot make any money for anybody, not even the creators.

I get that storing everything on the blockchain makes it transparent to the users, it’ll have to be encrypted. We’re not going to be the only ones with that problem, so I thought we’d cross that bridge when we came to it.

7

You just need a right mindset to make it work like you want it to work.

You can make money. If some player has a read-only access to some digital asset doesn’t mean that they possesses it (and that others admit this fact). You could sell this possession like any other bigtech sells you the possession of skins for your in-game character.

8

Oh no, I don’t want to make money. I’m funding the whole game and I have no intention for it to make a penny. Yes, early adopters and developers will get some sort of token that will hopefully increase in value as the game grows, but this is far from a capitalistic venture. I just want the game to reward people who participate and pay for its own bills.

2 Likes
9

I don’t know for sure the details of the Dfinity economics, but there is some stuff that I can predict with high probability.
As we know, the app owner pays for the app by himself. This means that an app (canister) should have some funds associated with its ID. To enable us to build autonomous software, Dfinity should also enable us to fund other’s canisters. This means that nothing stops you of making a simple html page with something like
If you like this app, please make a donation to this canister ID. It's current balance is N cycles - this is enough to run canister for X more days. We're not making any profits.

4 Likes
10

I think you could do something with three variables:

  • a global counter N
  • have a pseudo-random SALT salt that can be updated by an admin (can’t be read by the public)
  • a collision-resistant hash function h (sha256 from enzo for example)

let uuid = h(N + salt);

1 Like
11

At least node providers will be happy :smiley:

12

Here’s some example code that attempts to express some of what I think is intended here (but please correct me): https://github.com/matthewhammer/motoko-crud/pull/15

Some caveats that I know about now:

  • In my example, the service chooses the IDs (not the user of the service); either way is possible, of course, but the way I do it now is very simple (simple global counter)
  • No concerns for hiding IDs, or any data that they identity. Various workaround are possible, but as others have noted, real privacy will require more than what the IC platform has now. Exclusive control (access control) is possible now, of course. (Is that enough, I wonder?)
4 Likes
13

In your crud demo, what is CRU? I don’t see it defined anywhere.

14

Hey borovan, it’s a generic type standing in for whatever data you want to store, eg:
type Person = { name: Text; age: Nat; };

Would use

let myDatabase = Db.Database<Id, Person> ...

If you follow the imports back from Matthew’s GameEntities.mo you’ll find a good example structure for this, in examples/game/Types.mo: https://github.com/matthewhammer/motoko-crud/blob/master/examples/game/Types.mo

3 Likes