Scary to think how much my 5GB MC world would cost on the edge 🤣

I'm not looking to spend my life savings 😂

hey guys, let's try to keep the off-topic chat in #779390076219686943, thanks.

Hey everyone! I thought I had access to Durable Objects but I'm getting the

workers.api.error.not_entitled

error when trying to deploy with my account. Can I do anything about this? 😔

I'd suggest replying to the invite e-mail from Greg McKeon and tell him the problem.

do you have a Workers bundled subscription? DO only works on the paid workers plan (that's what i've seen causing this error most often)

@User oooh i see. I didn't know that, thanks!

i'm wondering how opaque a namespace's

idFromName

function is... given the result id, is it possible for someone to guess the input string? ie, can i, for example, use it as i would an HMAC function?

potential use case is a stateless authorization model: (1) user hits

/

(2) i call

crypto.getRandomValues

to generate a token, store it in their cookie (3) i call

idFromName

with (2) to redirect the user to a url like

/${id}

(4) i call

idFromString

to fetch the DO based on the url id from (3) (5) user shares the url with other users, who connect (6) i know which user 'owns' the DO because

idFromName(token)

===

idFromString(id)

.

note this is not stateless, the state has just moved to cookie

sure, and workers aren’t serverless, the server is just run by cloudflare. the point is the state is outside of the system.

I would recommend using

newUniqueId()

rather than generate random bytes and pass it to

idFromName()

. Note that the IDs it produces are unguessable, with at least 128 bits of cryptographic entropy.

with that said,

idFromName()

derives the ID from a secure hash of the input, so it is not reversible.

awesome, thanks @kenton. (i originally had

newUniqueId

as step one, but using it outside of stub fetching felt like an "abusage").

Is there a plan to have some kind of configurable ttl for durable objects (or its keys)? e.g. something that would clean up the storage if the specific DO wont get any requests/connections for 1 month

"Anyone with the link" sharing is an intended use case here. 🙂 That said, of course, you have to keep in mind that if someone hacks you (or... us) and gets a list of IDs then they can access all the objects. Whereas, with

idFromName()

, the name is not stored anywhere in our system. I'd like to add an option someday where you can opt out of being able to list the object IDs in return for a guarantee that there's no way for anyone to list them, and no way to access an object's contents without the ID (i.e. it becomes an encryption key for the specific object)... but we don't have that yet.

We're thinking of adding a general API to schedule a callback at a future time on a per-object basis, which you could then use to delete the object.

a persistent

setTimeout

of sorts? that's a cool idea.

Nice, that could definitely be used for other purposes as well, like it!

yeah it's pretty clearly a necessary feature for a lot of things. Not just for scheduling, but the ability to retry after failures (including hardware failures).

Is there a handler I can export to save in-memory state to the persistent datastore right before being evicted from memory?

my thinking is that way I wouldn't have to await on storage and slow down responses to clients

@User , does this help? https://developers.cloudflare.com/workers/learning/fetch-event-lifecycle#waituntil

i'm not sure if that's available within the context of a durable object

if it is available, that would probably solve my usecase 🙂

thanks

sure thing! let me know if it works out 🙂

(it is available, as a method on the

state

object passed to the constructor. see: https://discord.com/channels/595317990191398933/802187271067140107/807309699544121384)

Poll: For those who have built something with Durable Objects, do you prefer to put your DO class(es) in a separate script from your non-DO fetch handler, or do you prefer to combine them in one script?

^ @User