Hello,
After some prompting by Zachary, I'm posting an idea here.
Based on my understanding of the Wave Conversation Model, each
participant of a wave had their own user-specific wavelet for that wave
that resided at the server hosting their user account, and this wavelet
was never federated (no need). It stored information such as which
versions of blips had been read by the user (in order to implement
highlighting of changes since last view).
It occurred to me that this non-federated user-specific wavelet would be
a perfect place to store provider-specific features that are not
necessarily a part of the Wave Conversation Model standard, features
that would undoubtedly be built by implementers of the protocol, not not
necessarily adopted by all wave implementations. By doing this, the
wavelets that /are/ federated to other wave providers would not be
"polluted" with information they could not parse, or not pass properly,
and hence be "federation-friendly" for other providers.
Taking the idea a step further, it also makes sense that just custom
user-specific data would not be enough, and such providers would also
want to federate some information with other instances that support
these customisations that were implemented directly into the waves
rather than as gadgets. These could also be grouped into their own
provider-specific wavelets that are perhaps only federated to servers
that support the feature... or something like that.
Just an idea,
Sam
