Update schema methods to not generate id based on schema values about anoncreds-rs HOT 6 CLOSED

My suggestion would be to go for approach 2. I may have a high-level view, but I think would be good practice to apply a Builder pattern here, where atomically a scheme is created without an intermediate state, and I get back as a result an immutable object that later I'll publish to the ledger.
I imagine something like that :

schema schema_object = schema.buildSchema(anoncreds.buildId(), param1(), param2(), etc..)
ledger.publish(schema_object)

from anoncreds-rs.

@swcurran @blu3beri @victormartinez-work @dkulic Any thoughts on which approach would work best you think? I think approach 2 should be fine as you can almost always generate the identifier before you create the object, but curious to hear what you think.

For approach 1 the flow (in ACA-Py, AFJ) would be something like:

1. create schema without id property
2. call anoncreds method implementation to generate identifier
3. publish schema to ledger, get back schema object with id property

For approach 2 the flow would be something like:

1. call anoncreds method implementation to generate identifier
2. call create schema with id property
3. publish schema to ledger

I think the flow for approach 1 would be a bit cleaner as you don't have to go method specific -> generic -> method specific, but rather go generic -> method specific. However going with approach 2 makes the internal handling a lot easier as you don't have to make id an optional property on the schema model.

Edit: also tagging @andrewwhitehead

from anoncreds-rs.

One small, or big I am not too sure, benefit of the first approach is that we can easily reuse the anoncreds object to register it at different ledgers with different identifiers. If we take approach two we bind the id to the anoncreds object and therefore we cannot change it later, we have to regenerate it.

I am very unaware if this is a common use case, if it is it might be worth considering, but if it is not, I do not see a reason why we should not do Approach 2.

from anoncreds-rs.

Not sure what is the impact in case @blu3beri mentioned, but to me Approach 2 seams simpler and avoid confusion of having objects with and without an id.

from anoncreds-rs.

Approach 2 seems better to me, so that when you resolve the object you have a reference in it to where it was found. However, to resolve an object, you must already have its ID, so not really needed.

I assume we are thinking that whatever approach we use extends to all of the objects - CredDef, RevRegDef, RevRegEntry. In each, in theory, only the objects that reference another object must have the ID -- e.g. the CredDef must reference the ID of the schema, RevRegDef the CredDef, so in theory both work.

The identifier must be resolvable, so it's not like a database where you want content-less IDs that can be generated as the object is created. The IDs must be properly formed for resolution.

Sorry I'm not much help on this one...

from anoncreds-rs.

Discussed WG 2022-11-07:

• Id property is not needed in data model
• With some methods the id is generated during publishing (to the ledger), so approach 2 wouldn't work in that case

Proposed solution: do not include id in models, create objects without identifier (as the data model doesn't require an id)

from anoncreds-rs.