Hello, On 21 September 2010 02:13, Florent Le Coz <[email protected]> wrote: > Le 20/09/2010 22:31, Tuomas Koski wrote: >> >> IMHO it's up to the service to decide what kind of policy it follows. >> Let's not put that kind of business rules to the specs, right? >> > Au contraire, I think that it's important to specify how the user's > posts will be accessible. That's an (important) matter of privacy. > For example, RFC 3921 defines who can receive our presence, and that > kind of informations (that's the roster specification).
Yes, you are right. How ever in my humble opinion the access models and limitations are already defined in the underlying XEPs used. On 21 September 2010 02:13, Florent Le Coz <[email protected]> wrote: > Le 20/09/2010 22:31, Tuomas Koski wrote: >> As far as i'm concerned there isn't any kind of access control list we >> could not create for a node. Or am I wrong? > Yes, there is a way, see > http://xmpp.org/extensions/xep-0060.html#accessmodels Yes, I agree. That is what I was trying to refer to. On 21 September 2010 02:13, Florent Le Coz <[email protected]> wrote: > In my opinion, all the user's posts should have an access model of > Presence or Roster. (Roster would be better, this way you can, e.g., > post an entry that can be read by your friends and family but not your > coworkers) > Or at least, the user should be able to chose the model access of each > of his posts. > > In my opinion, one good way to do that (regardless of what is currently > in the XEP) would be: > > 1°) Romeo posts an entry about a cool website he just found, and decides > it's a public post. A node is then create in its microblog node, with an > Open access, in which an item represents his post. No one should be able > to post a new item in this node (or everyone? But that would make spam > easy…) > Anyone can then reply to this, the way it is currently defined in XEP > 0277 (http://xmpp.org/extensions/xep-0277.html#reply) i.e. by posting > your own new entry on your own microblog. > > 2°) Romeo now wants to describe the long trip he has made recently. A > node is created on his microblog, with a Roster access model. The first > item of the node is Romeo's post. Only the contacts in his Roster, in > the group Family are able to see this post. They are also able to post > in this node (publish only, no edition), to comment Romeo's post. > > To compare this with what already exists, we could say that 1°) is the > status.net/identi.ca/twitter way, while 2°) is the Facebook/diaspora way. > > I don't know buddycloud, but I assume that you're currently doing > something with an open access model, isn't it? > With my idea you'll still be able to do that, while also allowing some > private posts. In buddycloud we use the Open, the Authorize and the Whitelist access models as defined in the http://xmpp.org/extensions/xep-0060.html#accessmodels. We have also some custom affiliation states what the users can do when they have access. How ever it's still not right. Specially the interoperability with existing services is very hard. So what I'm actually doing right now is that I'm breaking things all up, study what other projects are out there are doing, what is their access models, relationships, reasons why they do so, etc. On 21 September 2010 02:13, Florent Le Coz <[email protected]> wrote: > What do you think about this? What I hope I could have written already is "buddylcoud implemented it's product as a prototype, it works, and now we would like to talk about the standard version of it." However, honestly, it's not the case. Buddycloud works pretty well on its own but it is not yet fully suitable as a federated system. I will write the first problem I'm having to a separate mail. It'll be surprisingly about disco#verability. I believe that the right way to build this kind of standards (XEP-0277) is to have a product problem, (try to) solve it, and then iterate with others on an open specification. Cheers, -- tuomas xmpp: [email protected] Ps. Is anyone living in Paris area? It would be a great "nerd fun" to discuss about these issues next to a beer.
