ralphmAlthough it might make sense for BuddyCloud, quipping "we tried to ignore as much of XMPP as possible" will surely be convincing.
KevPresumably it's relevant whether Simon's talking with his BC hat on or XSF hat on.
KevAnd if the former, we should find someone to talk to them with an XSF hat.
ralphmPeople don't generally distinguish hats at all
ralphmI am pretty sure that are a lot of people within the XSF that don't agree with that sentence or the design decisions behind it.
fippoi didn't talk there yet -- because it's way to tempting to say xmpp still has a presence scalability problem :-)
fippoi do actually agree with 'most applications assume presence is "one friend list to rule them all" - different apps have different social circles'
fippobut you can do that by extending the presence model of 6121
fippoi.e. the roster simply becomes a binary "known" decision used for filtering messages
dwdfippo, XMPP's basic <presence/> is universal, but PEP can be sliced and diced to different Circles^Wroster groups.
dwdCertainly in One Implementation That I Was Once Involved In, you could just set the access-model on a PEP node to be "roster", set the groups, and only those groups would see your atrocious taste in music, for example.
fippoyeah, we have the groups already. we don't use them extensively, but we might
fippoheh peter :-)
ralphmXMPP and PEP specifically are discussed at length in the 2013-10-31 meeting notes