Must be careful with the word "ecosystem." Ecosystem can mean different things depending on the purpose and architecture of an ecosystem.
First: about single-source information.
Although a wiki, in its true nature, allows editing of anything by anyone, I heavily dislike this kind of "Wild West" editing.
More pending ...
Fully independent TiddlyWiki instances.
None of them having copies of tiddlers from other TiddlyWiki instances.
None of them transcluding tiddlers from other TiddlyWiki instances.
Ability for a TiddlyWiki to display tiddlers (iframe) from other TiddlyWikis instances.
Ability to transclude data from other TiddlyWikis via "published data" tiddlers
More pending ...
a requirement for unique identifiers for every wiki
In the classic client/server model, a resource is “unique” by it’s URL. But this fails when that resource is served from multiple URLs, especially if it is served from multiple URLs on different Domains.
TW5 supports this out of the box, and has the concepts of “Authentication” (you are who you say you are), and “Authorization” (you are a “reader” or a “writer”), but not one of “Synchronization”. ATM, the TW5 server model is “poll the server once a minute for any changes”, which forces one to “edit serially, i.e. by taking turns” for any multi-device or multi-user scenarios.
In a federated model, each “wiki document” would have a UUID (universally unique ID), and this would be the “key” that let different instances of said wiki “talk to each other and synchronize”.
This is the model I am using at the moment, with the client/server back-end. But, you can even divorce this model from any back-end…
A federated ecosystem of TiddlyWiki instances makes sense in a scenario where TiddlyWiki instances directly transclude tiddlers from other TiddlyWiki instances.
I believe in an alternative architectural approach that avoids the requirements of a system to federate uniqueness.