Hi folks, we're going through https://authzed.com/docs/spicedb/concepts/expiring-relationships and noticed the newly recommended

<type> with expiration

delegates value of

now

to the underlying data store. About this: > It requires clients to provide the now timestamp. This is additional complexity for clients. Conversely, client-side provision of that value is crucial to our systems. We use TimeProvider abstraction in .NET that serves as the central source of truth for time, meaning we always override data stores' internal clocks by explicitly setting time columns/fields. Our TimeProvider is backed by different sources across projects, but what's important is that the app decides what

now

is, not any of the data stores or other infra. So we've skimmed and weren't able to find any notes on this: if specifying

now

for

<type> with expiration

is planned, unplanned or outright technically impossible to implement even in the future. If anyone could advise please. Thanks.

we currently don't have plans to implement a user-supplied

now

as an alternative. that said, that sort of expiration is something that you can implement yourself using caveats. you'll miss out on the automatic garbage collection, but otherwise one of the design considerations in the implementation of the inbuilt

expiration

feature was trying to avoid the client needing to supply a

now

.

if you plan to give your own time, we recommend using caveats

Ok, so it's unplanned but technically, there's nothing blocking a contribution from us or anyone else in future that implements this feature, correct? We're aware of caveats as an alternative and we understand the tradeoffs. It's not the first time we're considering adopting spicedb, really. We've had some architectural blockers to adoption in the past, but spicedb and our architecture has evolved a lot since then that this is has become the only blocker left. The caveat pattern won't get past prototype to prod because the spicedb docs page discourages that use case, and with good reason (the new pattern is evidently better). At the same time, our centralized approach to sourcing time isn't going to change. Thanks for explaining. I did come up with an adhoc approach that reads the time from the db and schedules expiration with that reference, but that was just good enough for a prototype.

> because the spicedb docs page discourages that use case only because 99.9% of people can use the built-in

Thanks for clarifying. It's hard to argue for caveats because we've had mixed opinions on its expression/syntax before the newer approach to expiration was added. The newer approach significantly simplifies our proposed schema to a point where caveats look "dirty" in comparison. I understand we're likely the 0.1% who need this, which is why I needed to find out if the lack of support for this is perpetual, so we know to check back for it or try contributing, and if not, pitch caveats again, which helps us decide on spicedb once and for all.

the problem with contributing it is time skew

That's would suffice for our use case indeed.

so yeah, in that case, we'd likely accept the contribution

Yes. Absolutely.

okay

Yes, I think spicedb-wide makes sense for uniformity. It's an architectural decision to supply time from the app or delegate to the data store. Allowing some requests to behave differently would only serve to complicate things. Should I go ahead and freeform a proposal on github or do you want it structured a certain way?

freeform is fine

Alright.