# To indy or not to indy?
> Paul Bastian(Bundesdruckerei), Christian Bormann(Bosch), Michael Schäfer(Bosch)
- only talking about the indy network (indy-node/indy-plenum)
- Anoncreds/DIDComm are independant from indy (misconception!)
- this document does not discuss AnonCreds/DIDComm (out of scope)

# Requirements and needs?
- regulatory safeness
- longterm commitment & active developer community/contributions
- technical stability and scalability
- but: network is just an enabler/tool
- business cases rely mostly on higher level functionality
- DIDComm and AnonCreds as important building blocks independant of Layer 1

# Status Quo : Indy Network & Consensus
## Pros
1. **Efficient signature scheme for node consensus & State proof**: Check validity of provided information as client (via efficient aggregated bls signatures)
- this property is really important for scalability and trust relations and currently missing in other DLT
2. Role / Permission based / configurable during runtime (via config ledger)
3. Plenum (with own RBFT implementation)
4. Purely for identities – no tokens involved

## Cons
1. currently not many active contributors & missing political support
2. Throughput bottleneck (observer concept & implementation required for production)
3. BLS is new crypto (regarding regulated use cases)
4. Purely for identities –> no smartcontracts and requires parallel setup for payment

# Path forward
## Alternative 1
- indy gets political support
- indy contribution is driven by the IDunion SCE
- commitment of the IDunion partners
- fix immanent problems for production (e.g. observer pattern)
- possible roadmap:
- finalizing did:indy
- **build concepts and integrate observer pattern**
- build concepts and integrate deletion/tomb stoning
- maintenance work
- set up production network

## Alternative 2a
- commitment to an existing (permissioned) network
- e.g. EBSI
- add desired features to new network (mostly agent side)
- e.g. DIDComm, AnonCreds support
- initially additional effort with few benefits, long-term probably less effort
- adaption of existing use cases
- EBSI is currently a technical inferior solution and is **very likely subject to change**
- possible roadmap:
- start with evm-based EBSI (did:ethr?)
- optional : build concepts to improve EBSI (BLS/state proof/roles?)
- build concepts and integrate deletion
- **build concepts to integrate Aries/DIDComm/AnonCreds**
- **integration into aries frameworks**
- integration into current pilots

## Alternative 2b
- commitment to building a new network
- design new network with given requirements from scratch/re-using existing components (e.g. ethereum/tendermint/cosmos)
- risk/reward ratio?
- integrate experiences from current solutions
- better programming languages
- possible roadmap:
- did method/specification
- start with cosmos/tendermint
- build role concept
- integrate BLS/State-proofs
- build concepts and integrate deletion
- client libs(like indy-vdr)
- **integration into aries frameworks**
- integration into current pilots
- set up production network

## Alternative 2c
- use TrustChain as VDR from one of the IDunion partners
- TrustChain needs political support
- strong focus on HL aries
- risk/reward ratio
- same focus like indy but learned from mistakes
- already solved scalability and GDPR problems
- Open Source and "made in Germany" (gets support by politicans for sovereign solution)
- no implementation for Anoncreds yet but for VC already
- further investigation neccessary
- roadmap:
- intergrate Anoncreds when standards are finalized
- get support from BSI for regulated/relevant use cases

## Alternative 3
- do not use DLT as Verifiable Data Registry
- use did:web(every issuer hosting his keys on his own webserver), did:keri
- **many unanswered questions as well - research necessary**
- less SSI centric - verifier contacts issuer directly (escpecially for revocation)
- trust framework & governance

# Next Steps
- who takes the decision?
- discussion with EBSI guys?
- separate workshop?