You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I mint a minid two times in a row (same checksum, etc.), the server mints new minids both times - shouldn't the server refuse to make a new minid if the entity already exists?
I thought the intention was to allow different users (identities) to create minids for the same object. It does seem redundant to allow the same user/identity to create a new minid for an object that they have already created one for. They should be updating that existing identifier rather than peeling off a new one. Maybe this is just a bit of missing logic on the backend?
I thought there was a check somewhere to see if the checksum already existed. It'd make sense to me to have a 1:1 mapping of checksums to minids, but a minid can have many locations... location-parsing is up to clients for now, I think.
If I mint a minid two times in a row (same checksum, etc.), the server mints new minids both times - shouldn't the server refuse to make a new minid if the entity already exists?
Here's my second minted minid for the same json:
The text was updated successfully, but these errors were encountered: