I’m quite confused how a Membership application will cover managing address mappings to entities that aren’t in Aragon?
Let’s call this pattern a “translator”. A translator translates an Ethereum address (0x…) into a human-readable name.
Why not allow the system to be flexible enough to sync up with multiple translators [translation providers]? Then it will cover the broader use case of translating addresses that aren’t individuals or Organizations that are using the Membership app? Instead of trying to tie everything to one elegantly designed translator, let a few of them co-exist (especially since the elegant design doesn’t cover all translation use cases)
If there are multiple translation providers you enable for your DAO, you can also rank them, so if the translation exists in two or more providers, then it will display the translation from the highest-ranked provider.
Does this solution really add that much technical debt? Like if someone doesn’t want to have two translators, then they don’t have to have it. If someone does, then it just does something different when loading the front-end?
I think the greater technical debt can come with designing a system that is not flexible and is tied to a single application to provide such a service. As seen on this thread, organizations have different needs, so how can the aragon architecture be designed in such a way that it can more easily cater toward those needs, instead of assuming there is a silver bullet solution to this use case that goes way beyond membership/identity ?
Note: this translation provider topic is a bit of a “fork” from the original thread, not sure if another thread is necessary to have more focused discussion on the topic, so it’s not confused with the solution presented here.