I agree, you can get your own hex id from inside the DO using

state.id

, but it would be nice to have the other stub specs (

name

,

jurisdiction

if applicable) without having to pass them down into every call (what I'm doing now).

not sure if theres an example, but im rolling my own durable based auth also

the documentation isn't really explicit on how the durable should communicate with the worker, so im just having it behave like a rest api in the sense that the worker can perform ``GET``, ``POST``, ``PUT`` and ``PATCH`` operations on the users DO

still not sure how im gonna handle TOTP and stuff (yet)

It's probably been asked before but is there any way to list / delete Durable Objects?

@User Thanks for the quick answer, but I don't mean the DO's internal storage, I mean the whole thing.

So when I initialize a durable object it gets created somewhere on a server, but once I don't need it anymore how do I get rid of it?

Or is my fundamental understanding of how Durable Objects work just wrong?

Your understanding is spot on. You can't do this as of today, you must remember the id/name for each object yourself (maybe in another DO!) and

deleteAll

from within each instance. I seem to recall someone from cf mentioning they are planning to have some sort of management api surface for DOs as part of the standard cf rest api by the time DOs hit GA, but I couldn't find it in scrollback, maybe a different channel.

So if I clear its internal storage we're good?

yep - that's the only storage you're charged for, and make sure you don't amass 10gb across all instances in your account during the beta

Does that even work when I'm using web sockets within my DO?

hehe, yea the

state.storage

is available in any DO instance constructor, including ones that handle websockets. Websockets themselves have no durable state outside of the instance that you need to clean up.

Thank you John for the clarification 🙂

@User Make this man a Community Champion 👏😊

KV is encrypted with 256-bit AES-GCM. Is DO storage the same? Can't see it said definitively anywhere.

DO storage is encrypted at rest

Same standard?

It's a different system but also AES256

Awesome, thanks!

Does a DOs internal storage also have up to a 60 second delay until it can be reliably read back?

nono, DOs storage is consistent, as there is no global replication in play (you always have one DO instance per DO id running, talking to a single storage)

@User Thank you 🙂

Yep, to be clear it is replicated, so that we can fail over if a data center were to suddenly go offline, but it's not like Workers KV

Speaking of listing objects (from earlier), if anyone wants to test it out, I can give you the details

yes please! 🙋‍♂️

will be nice!

I've DM'd both of you, and probably tomorrow I'll post the details here for the channel

i’m looking to mock Durable Object ID generation… can you tell me what flavor of crypto is used to ensure that a given ID was generated for a given DO? (ie, can’t just use random strings for

idFromString

)