>> We are solving this a different way in onesocialweb and this could >> become an extension to PEP and/or PubSub. Here is the flow: >> >> [removed the flow] >> > Okay, so let me see if I follow. > > Conceptually, then, this is the user's account itself subscribing to a > remote PubSub node, and then the user's clients are then subscribing to the > user's own PEP node which acts as an aggregator?
Yes. > From an implementation standpoint, this means the server has to look inside > messages inbound to the bare jid. I'm not *wholly* against this, because > these are fairly rare, comparitively - in fact, I think the vast majority of > such messages I get are already identi.ca ones - but in general I'm not keen > on servers having to look "inside" without a type indicator, and I don't > think adding a type is practical. Yes. Today it is implemented by intercepting inbound messages to bare jids, opening them up, checking if they are pubsub events messages, and applying our logic if it is the case. We could avoid having to inspect all messages if using a new type (or another attribute at the message level). May I ask why adding a type is impractical ? What about another attribute ? Is XMPP not extensible also at attributes level ? > So instead, I'm thinking about whether a subscription type of "republish to > me" is actually the way - ie, when I publish an item, my server republishes > it to the PEP nodes of each subscriber in turn. (And yes, this technically > isn't PEP as such anymore, it's some form of PubSub-onna-jid). The downside > is that this means that the S2S traffic is now an <iq/> pair, but that does > give us some form of reliability and error control. I like that one ! The user has a 'inbox pep node' where everyone can write (or the user could even decide who is authorized to write) and only the user can read. Clients use presence based subscriptions to be notified of new items. I also agree to the benefits of having IQ delivery for better error control. >> What do you think ? Worth moving forward as an extension to PEP or >> PubSub (e.g. PubSub inbox protocol). Is there other ideas/proposal out >> there on the concept of a PubSub inbox ? > > No, I do generally like the concept. I'm just wondering how to make it more > palatableThe thing I like more is the notion that this could unify the likes > of status.net and onesocialweb - I think that in itself is pretty > interesting. > Will sleep on it and confront our use cases to this. I'll put together a first draft of an example flow as support for discussion. Thanks for the feedback !
