I really don't know enough about Evolution to be sure on this but I have this thought....
What I'd like to see (and maybe development is heading this way?), is the dash MN daemon to remain relatively static / unaltered, save security updates, and then things like username lookups to be implemented as optional plugins. Dash would become an open pluggable platform whereby MNOs could choose the plugins and services they provide. For example, an incoming transaction might utilise a username ("Evolution") plugin. Or maybe, for example, an "SMS" plugin. And so the quorums would be formed by participating nodes running said plugins.
I think this would be a real boost to everyone because it would mean no forking or forced upgrades. MNOs would be less dependent on one core development team and would have more autonomy on dash's direction.
Over time, we've seen many development suggestions but we're ultimately held to the beck and call of a few developers. A plugin system would vastly liberate MNOs.
One possible downside might be, for example, if only a few nodes are running the Evolution plugin, then security might be compromised. However valid this is, that choice is better placed in the hands of MNOs and users, determining their own future. As a user, it's for me to decide if I accept only X number of MNs are running a particular service. One of those services might be, for example, payments by SMS... not every MNO would want to operate an SMS service, but some might if there was additional revenue. Equally, not every MNO would want to operate over the same SMS provider... a pluggable system would provide that kind of freedom. A wallet provider would simply request an "SMS" transaction type and an appropriate SMS quorum would be formed. But in any event, it's perfectly possible that a MN plugin could require X number of quorum participation.
Another example might be payments using DNS, which someone else had suggested. Typically, these kind of suggestions go nowhere because only a few developers will agree. (much, in the same way, not everyone is liking the email function of Evolution).
How about exchange plugins. A dash wallet issues a transaction type "dash-to-bitcoin" with various criteria and the resulting quorum is formed using competing MN exchange plugins.. thus ensuring end users get the best possible rates, yet not hard wired into the wallet itself.
Yes, many of these ideas can be done on the client side, but I think giving developers the choice to develop plugins on the server side would open a whole new world.
Or maybe I've lost the plot...
What I'd like to see (and maybe development is heading this way?), is the dash MN daemon to remain relatively static / unaltered, save security updates, and then things like username lookups to be implemented as optional plugins. Dash would become an open pluggable platform whereby MNOs could choose the plugins and services they provide. For example, an incoming transaction might utilise a username ("Evolution") plugin. Or maybe, for example, an "SMS" plugin. And so the quorums would be formed by participating nodes running said plugins.
I think this would be a real boost to everyone because it would mean no forking or forced upgrades. MNOs would be less dependent on one core development team and would have more autonomy on dash's direction.
Over time, we've seen many development suggestions but we're ultimately held to the beck and call of a few developers. A plugin system would vastly liberate MNOs.
One possible downside might be, for example, if only a few nodes are running the Evolution plugin, then security might be compromised. However valid this is, that choice is better placed in the hands of MNOs and users, determining their own future. As a user, it's for me to decide if I accept only X number of MNs are running a particular service. One of those services might be, for example, payments by SMS... not every MNO would want to operate an SMS service, but some might if there was additional revenue. Equally, not every MNO would want to operate over the same SMS provider... a pluggable system would provide that kind of freedom. A wallet provider would simply request an "SMS" transaction type and an appropriate SMS quorum would be formed. But in any event, it's perfectly possible that a MN plugin could require X number of quorum participation.
Another example might be payments using DNS, which someone else had suggested. Typically, these kind of suggestions go nowhere because only a few developers will agree. (much, in the same way, not everyone is liking the email function of Evolution).
How about exchange plugins. A dash wallet issues a transaction type "dash-to-bitcoin" with various criteria and the resulting quorum is formed using competing MN exchange plugins.. thus ensuring end users get the best possible rates, yet not hard wired into the wallet itself.
Yes, many of these ideas can be done on the client side, but I think giving developers the choice to develop plugins on the server side would open a whole new world.
Or maybe I've lost the plot...