Well think about it this way. Developers make for the users, and the simpler the development pipeline is the closer that we can bridge that gap between the developer user and the non-developer user.
If we can make things simpler, that means that more people can make edits and changes to diversify the ecosystem to find the best practices that will suit all users. If it’s a black box, it’ll never get changed, fixed or improved on.
e.g. in practice: Flow app. Great app, but of course plenty of things we would want done to it. Guess what? No one does those edits. Why? It’s all freely available in one JS file right there! Well because it’s too difficult and therefore not worth many people’s time. Result? Nothing gets iterated on. Dead-end until the original devs decide to move forward with it.
This hurts the developers, and since developers can’t fix it, it hurts the users. All users.
I’m advocating for a system that is easy on developers and therefore easy on the users, and everyone in between.
Fact: We have more people on High Fidelity that know how to script basically in HiFi (at least at a beginner level) than know how to utilize and extend XMPP. That in it of itself puts XMPP in a poor position.
There are ways of using the Private/Public key pairs that already exist in HiFi and core systems that can be used to send messages. It already exists and with some wiring up, it would be all operational and scriptable. In the end, the idea should be to make this simpler and of course more secure. Using private/public key pairs at least means that the carrier need not matter for now as it cannot be broken otherwise unless someone had your key. This means we can expand and carry our messages over websockets later if we wanted, it doesn’t matter!
Utilizing existing systems and expanding on our current API is all that it would take to make this work, then we can expand in other ways if we wish. But at least we have a baseline set that anyone and everyone can understand.
Generativity cannot happen in a black box.