Complete: ICDevs.org Bounty #3 - ULID motoko library

Developers Bounties
,
3

I thought of you when I wrote this up. I would imagine this would be a pretty simple one for you. I know you are slammed. Know anyone else that would benefit from tackling it? UUID v4 is coming next week, so maybe you already have that one written?

4

I know you are slammed.

Maybe I have already played around with it… and as a result, a working prototype. :wink:

But I’d like to discuss the Random part of it, my current POC uses Random.blob, which is async. Is there a preference, sync vs async?

5

Good stuff here, I tried to tackle this in the past: UUIDs generator
@quint your UUID lib is amazing but my concerns regarding any uuid generator are:

  • collision probability
  • costs
  • async time delays.

The UUID’s in our app will be visible so a simple int incremental won’t just do it. Also we can’t rely on the client to provide any “help” in this process.

6

Here are some links:

Maybe we need to create a new UID standard based on time, canister_id and principal_id?

1 Like
7

These should be very low, since a ULID also contains the time of creations, and the other part is not just incremental. So you shouldn’t be able to just guess an ULID.

  • I still have not found a good way to test costs on the IC, so I have no idea, maybe I’ll do some benchmarks on a test canister.
  • Another one that can be included in these tests, I’ll provide some updates soon.
8

Looks like you are proactively working on this? Awesome! I have two thoughts about randomness. I think the libraries should have two modes. One that uses randomness to produce true random IDs that produce crypto secure IDs and then another mode that uses pseudo-randomness. Maybe we hash something like a blob of (Principal, timestamp, nonce). The random one will obviously take an extra round to produce which is a bummer but at least it will be offered. The pseudo-random should be ok…I really wish that motoko would expose the block or message ID in the msg variable so we could use it for this purpose. Maybe I will post a message on the forum about it.

2 Likes
9

The UUID package I wrote is based on pseudo-randomness.
The ULID package currently uses Random.blob as a source.

I’ll make sure the packages have both options.

How would a pseudo-randomness interface look like? Do we need a standard for this?
I used my IO package, but I am not sure if this is the way to go forward.

10

It looks like we may need to put in some requests with the Motoko team for some proper pseudo randomness. See Exposing Message ID or Message Order in a block to motoko - #4 by nomeata

In the meantime, we are going to have to look it up. I’ll take a look at UUID and see how you did it. It is probably sufficient for now.

11

Looks like you let the user supply their own randomness with:

public class Generator(
        rand : IO.Reader<Nat8>,
        node : [Nat8],
    )

What is the node? I like this approach because you can stick the IC random entropy in there if you want it and it lets the user decide to do their own psuedo randomness. If they want to hash Time.now() they can…or Time.now() / nonce or something like that.

12

This is just based on the spec.

In version 1 of UUID, a node consisted of an IEEE 802 MAC address, usually the host address. Now these are drawn from, and unique within, some “name space”.

In our case this can be the canister ID f.e., or just some random entropy (it has to be 48 bits tho…)

13

Ok…so an easy function to translate a principal to 48 bits would be a good utility function to have.

Maybe just Hash(Principal) # 1stHalf of Hash(Principal)?

14

I updated the ULID package. In now includes both an async and sync option.
There is also a small example.

2 Likes
15

This Bounty is under review to be awarded to quint! Please review and provide comments at GitHub - aviate-labs/ulid.mo: ULID Generator for Motoko

1 Like
16

Bumping this post. :inbox_tray:

17

Same with this one. 24 more hours for comments or requests and then I’m going to award the bounty.

18

This Bounty has been closed out and awarded. Quint elected to forfeit the prize back to the ICDevs treasury as part of his joining the Developer Advisor’s Committee Board. We appreciated the donation and are super excited to have Quint’s influence on board. Quint has contributed an immense amount of code to the motoko ecosystem and we should all recognize his significant contributions.

Go Quint!

5 Likes
19

What’s Canister ID “f.e”? I didn’t get what f.e. is.

20

any update on async delays?

21

What concerns do you have about async delays? The way random() works on the IC has an implicit delay(which helps in sure randomness). If you want “true” randomness I don’t think you can avoid it. If you just need psuedo-randomness I think that is supported without the use of async.

22

I read it as “for example”.

1 Like