> > >I think that the protocol should capture the threading information, and > leave it up to the clients to decide how that is presented to the >users. > Some will prefer the twitter style (reflecting maybe better the way > conversation may happen in real life) and the more regular >commenting > style. > > > > How would threading work then in a real implementation? In the situation of > A, B, C where B and C are only subscribed to A and A posted something to A’s > PEP node and B posted a reply which only goes to B’s PEP node, how would C > ever get that message? Would the implementation send it to C somehow (and > how, a PEP message?) > > In our implementation, when B and C reply to A, they are in fact commenting on A's item. This means that post their reply to A and A is rebroadcasting it based on the initial privacy rules attached to its item. Now, if B and C also wants to post it to their node, they can, but therefore they may expose some content that A did not want to see rebroadcasted.
> It seems like in twitters model the conversation thread is not the central > thing, but the user is. This results in twitter streams looking like a lot > of people “talking past” each other. It’s a very bad model, there isn’t any > conversation or communication in twitter, just a lot of disconnected posts. > In my opinion the conversation thread should be the key element. Users > should contain threads which could be subscribed to. > > Let the user decide. We support both. A twitter style model where users 'shout' at each others (our equivalent of @replies) and threaded commenting on a per item basis (like in Facebook and Google Buzz). > Maybe I am in the minority, but I prefer to follow threads of > conversations of interest, not everything a person chooses to post. > Our protocol supports both. Clients decide what they implement and how they present it to the user, and hopefully there will be enough choice for you to pick a client that suits your needs. Thanks for the comments ! Laurent
