stupid question; i might have missed something - but i cannot grant access to a certain amount of puts - can i?
how would i stop an app from creating many many random mutables and just destroying my put/safecoin account?
1 Like
There are no limits atm, though some ways of doing this were discussed a while ago. I expect it will be revisited.
2 Likes
I’m wondering if that idea of using Macaroons could also support such a permission/caveat? (I suspect so, but willing to hear more knowledgeable people here)
3 Likes
The wallet app would keep track of the available balance for all the apps, and it would create 3rd-party caveats (that would include the current balance and would expire very-very quickly) that those apps would have to attach to their requests alongside the original credentials, because those in turn would refer to the 3rd-party caveats as one of the requirements. I suspect any given wallet would be managed by the same section or group so it wouldn’t be hard to include protection against double-spending before the 3rd-party caveat expires.
I think this wouldn’t be possible though, the vaults don’t have a time to compare against, but caveats perhaps can have just a tiny amount of credits/PUTs and they’ll need to renew it with the wallet app as you describe.
I’m not sure that has to apply here. Computers in general can have a sense of time through NTP and that’s enough because we’re talking about a simple spot-check against a timestamp on the credentials, not something fundamental to how vaults otherwise function or store data.
Actually, much of the auth checks could be done at a very low level: signature match, expiry, write request with just read rights, and other stuff like that, which are all simple things that can invalidate a request without having to look at anything Safe Network specific. In effect, vaults still don’t need no have any idea about time, just like they don’t have to know about the TTL of network packets and other low-level stuff.
What I was thinking was that if the network doesn’t use time as a tool then using any type of local sense of time is incorrect as that wouldn’t be an “agreed” time/check made by the network.
I get that, but what I’m proposing falls squarely into “nodes may use local durations” category. Time is not used for intra-node things here, only as a static consistency check to verify if the request is valid. If it isn’t, it wouldn’t even get passed on to the vault logic.
Compare it to lower level networking. If a router somewhere rejects a packet due to its TTL going to zero, the Safe Network is in no way affected. It is the same with adding expiry times as caveats to macaroons. Also, if something expires by accident, the client can just repeat the request; there’s no damage.
Double spending can be avoided if macaroons with expiry are single-use (that is, remembered through their expiry date) but that’s only possible if subsequent requests are going to the same section. I think that would be the case with wallets, for example. Expiry periods would have to be limited to short times to avoid abuse.
Anyway, this made me think and it seems most of the authorization verification could be done before the vault logic because much of the auth control is just verifying if a request is matching the credentials. Things like requesting a write operation with a macaroon that has a caveat that removes write access, or signing a request not with the key that a caveat demands, these can be safely rejected before checking anything on the network.
Now, the network would still have to check things like “the referenced object is owned by the root key of the credentials presented” or “the wallet does indeed contain this coin” and the like, but that’s not additional work compared to today.