astral crater
I noticed when we updated to auth-next, we kept soroban-auth and put the auth logic into that crate. The reason we had a separate crate for auth was because auth was outside the protocol. Now that auth is first-class, we can move the logic from soroban-auth into soroban-sdk so that folks get access to auth as part of the default set of sdk utilities.
Is anyone opposed to doing this? cc @arctic sage
arctic sage
this has been repurposed for the account contract support - it's not needed for generic contracts
the naming is a bit of a mess - we've used it because the crate name got stolen before we realized, though IIRC it should be available now... maybe just rename?
astral crater
this has been repurposed for the account contract support
How much functionality will there be? Looks extremely light at the moment.
arctic sage
yeah, I'm not sure if we can provide much more, so I wouldn't be too opposed to merging this back to sdk...
it just seemed a bit unrelated to what sdk does, similar to e.g. token spec
astral crater
Fwiw the token spec is likely moving into the sdk.
The token spec was separated because we were exploring with how to produce the contract spec, but I think we'll service all use cases moving it in. @boreal reef is exploring that afaik.
The auth crate was separated because it was just an idea built atop of the protocol in user space, but that's not the case anymore.
Account contracts are so specialized that yeah might make sense to keep it separate.
But doesn't seem like there's much there.