[Standards] Categories in the Bookmarks XEP
I have implemented the Bookmarks XEP (http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/) to store the conferences, URL and subscribed Pubsub feeds of the user. Maybe it can be a great idea to add a category tag with some default categories like news, blog, nsfw... With this kind of feature I'll be able to tag more precisely the Pubsub items and maybe add special behaviours one some of them (like hide by default the content of the nsfw items or display in priority the news items). What do you think about this ? Tim
Re: [Standards] Categories in the Bookmarks XEP
On 8/15/13 2:26 AM, Jaussoin Timothée wrote: I have implemented the Bookmarks XEP (http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/) to store the conferences, URL and subscribed Pubsub feeds of the user. Maybe it can be a great idea to add a category tag with some default categories like news, blog, nsfw... With this kind of feature I'll be able to tag more precisely the Pubsub items and maybe add special behaviours one some of them (like hide by default the content of the nsfw items or display in priority the news items). In general, tagging is a good thing. :-) Do you propose that we add a 'tag' attribute to both the url/ element and the conference/ element? Would it contain a space-separated list of tags? Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On 20 jun. 2013, at 05:14, Peter Saint-Andre stpe...@stpeter.im wrote: So when we wrote XEP-0178 this was fairly vague, but the upshot is that it probably needs some revision: 1) The right way to specify the jid you're expecting to become is by using the from attribute of the stream. This is most especially true for servers. I'm still not sure I understand 10(c), though. Does the address specified during SASL negotiation refer to the from attribute on the stream? IMHO that would indeed be the 'from' on the initial stream header. It would be good to clear that up in the spec, eh? Peter There's one more point I want to make about this, not exactly related, but close enough to continue this thread. The security considerations section of XEP-0178 states only: This document introduces no security considerations or concerns above and beyond those discussed in RFC 6120 and RFC 6125. While that may be true, there's one thing that might warrant some emphasis: Both the server's and the client's certificate are sent in plain during the handshake. This means that any id-on-xmppAddr attribute, common name field or any other personal info on the certificate will be visible to any passive observer of the stream. Every client I've used tries to avoid leaking your identity before TLS is active (no 'from' attribute on the initial stream) and this could break that. Even when a user is using a certificate with no personally identifiable information at all, just by looking at the public key an observer could try to correlate different connections to the same account. In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation as a way to protect the client's certificate if it's known to be private. I guess this would work, though I'm not sure how well-supported that is. I think it would be good if XEP-0178 at least mentioned that the certificate is sent in plain and pointed to §5.1.3 for a workaround. Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Categories in the Bookmarks XEP
Le 15/08/2013 19:47, Peter Saint-Andre a écrit : On 8/15/13 2:26 AM, Jaussoin Timothée wrote: I have implemented the Bookmarks XEP (http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/) to store the conferences, URL and subscribed Pubsub feeds of the user. Maybe it can be a great idea to add a category tag with some default categories like news, blog, nsfw... With this kind of feature I'll be able to tag more precisely the Pubsub items and maybe add special behaviours one some of them (like hide by default the content of the nsfw items or display in priority the news items). In general, tagging is a good thing. :-) Do you propose that we add a 'tag' attribute to both the url/ element and the conference/ element? Would it contain a space-separated list of tags? Peter Hi ! I've also added a specific element to bookmark the pubsub nodes, this way : pubsub xmlns=http://jabber.org/protocol/pubsub; items node=storage:bookmarks item id=current storage xmlns=storage:bookmarks conference jid=mo...@conference.movim.eu autojoin=1 name=Movim nickedhelas/nick /conference subscription xmlns=urn:xmpp:pubsub:subscription:0 subid= node=BouletCorp server=pubsub.movim.eu title/ /subscription subscription xmlns=urn:xmpp:pubsub:subscription:0 subid= node=CerealesMatin server=pubsub.movim.eu title/ /subscription subscription xmlns=urn:xmpp:pubsub:subscription:0 subid= node=Chez_Kek server=pubsub.movim.eu title/ /subscription subscription xmlns=urn:xmpp:pubsub:subscription:0 subid= node=JournalDuGeek server=pubsub.movim.eu title/ /subscription subscription xmlns=urn:xmpp:pubsub:subscription:0 subid= node=LinuxFr server=pubsub.movim.eu title/ /subscription /storage /item /items /pubsub We can maybe re-use the same tag system than for the atom elements : conference jid=mo...@conference.movim.eu autojoin=1 name=Movim nickedhelas/nick category term=Movim/ category term=XMPP/ category term=Jabber/ /conference It's just an idea :)
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On Thu, Aug 15, 2013 at 8:47 PM, Thijs Alkemade th...@xnyhps.nl wrote: Both the server's and the client's certificate are sent in plain during the handshake. This means that any id-on-xmppAddr attribute, common name field or any other personal info on the certificate will be visible to any passive observer of the stream. Every client I've used tries to avoid leaking your identity before TLS is active (no 'from' attribute on the initial stream) and this could break that. Even when a user is using a certificate with no personally identifiable information at all, just by looking at the public key an observer could try to correlate different connections to the same account. Yes, but I don't think that's a particular point in mind with XEP-0178, or indeed XMPP in general. In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation as a way to protect the client's certificate if it's known to be private. I guess this would work, though I'm not sure how well-supported that is. Hmmm... I know at least some implementations might struggle. You'd have two negotiations, and you'd have to hope that the server looked at the one you wanted. I think it would be good if XEP-0178 at least mentioned that the certificate is sent in plain and pointed to §5.1.3 for a workaround. I'd much rather we investigated the practical implications - '178 is intended as best practice, so it'd be nice to know it worked.
Re: [Standards] Categories in the Bookmarks XEP
On 15 August 2013 18:47, Peter Saint-Andre stpe...@stpeter.im wrote: On 8/15/13 2:26 AM, Jaussoin Timothée wrote: I have implemented the Bookmarks XEP (http://xmpp.org/extensions/xep-0048.html) in Movim (http://movim.eu/) to store the conferences, URL and subscribed Pubsub feeds of the user. Maybe it can be a great idea to add a category tag with some default categories like news, blog, nsfw... With this kind of feature I'll be able to tag more precisely the Pubsub items and maybe add special behaviours one some of them (like hide by default the content of the nsfw items or display in priority the news items). In general, tagging is a good thing. :-) Do you propose that we add a 'tag' attribute to both the url/ element and the conference/ element? Would it contain a space-separated list of tags? Adding repeatable 'tag/' subelement looks like much better idea to me and will avoid limitations of having a separator. -- Best regards, Maxim
