Re: [Standards] Deprecating IBR
For buddycloud we use IBR on localhost that the API talks to. It definitely has it's place. Perhaps a better approach would be to adapt xmpp.net to also test for insecre IBR. S. On 4 November 2015 at 14:58, Peter Waher wrote: > Hello > > While I'm for deprecating unsecured IBR, IBR still has an important role > in automation, especially in IoT, if it is made secure, as proposed in > XEP-0348, §3.1. It provides a means of controlling amounts of accounts that > can be created, and by whom (parties trusted to create certain number of > accounts). > > Perhaps an overhaul of this process, or a new process that permits > automatic Creation of accounts in a controlled manner, is better than just > deprecating IBR without providing an alternative. > > Best regards, > Peter Waher > > > So, something for next Council to ponder: > > > > In light of spam attacks using throw-away accounts, and given than 77 is > final and we?re not going to be able to mandate a significant overhaul, is > it time to deprecate (and obsolete) 77 and send a clear message that this > should not be being used on open networks? > > > > /K > > -- Simon Tennant | CEO Buddycloud <http://buddycloud.com> | +49 17 8545 0880 | Meet <https://calendly.com/simon-tennant/buddycloud-call>
[Standards] "I've read up to here" stanza?
In yesterday's Buddycloud dev call we were talking about syncing read-states in a multi-client scenario. Problem: - Sync the "I've read up to here" state between multiple devices. Imagine the scenario where you have been chatting on your phone, come home and pick up your Tablet: it should scrolling to the correct part of a chat. - See where participantX has read up to in a chat, buddycloud-channel or ephemeral channel. Hangouts and WhatsApp have a similar mechanism where the avatar pictures move down the chat window to show where your participant has read up to. It would be nice to include this. dwd pointed out that this might not scale well to rooms with very large participants counts. I still believe there's value in 1 to 1 chats and showing participants' state for smaller channels. It would be nice to have a generic IQ that can be sent back to either the XMPP server or pub-sub component to indicate the "I've read up to here" state: - Clients would optimise how often they send this state. - The server could stop sending "participantX has read up to messageID/timestamp" when a group is greater than a certain number of participants. Georg started mentioning this https://www.mail-archive.com/standards@xmpp.org/msg14067.html (see: MARK AS READ) Is anyone else thinking about this or have any stanzas to share? S. -- Simon Tennant | CEO Buddycloud <http://buddycloud.com> | +49 17 8545 0880 Book a Buddycloud call <https://calendly.com/simon-tennant/buddycloud-call>
Re: [Standards] XMPP GSoC ideas
It should be pointed out that Kev always does an amazing job on the GSOC application and general XSF project cat-herding. Thanks Kev. Now lets hope the XSF gets selected for GSOC this year. S. On 19 February 2015 at 18:07, Kevin Smith wrote: > Thanks to everyone who’s sent in ideas. Some contributions have been more > involved than others - can everyone who’s sent me text please check that > all the fields of the template are filled with enough information for > students to understand what’s required of them. Particularly that ‘expected > results’ should be a set of deliverables, not ‘complete the project’ type > comments (particularly as we’ll be wanting mentors to work with students to > ensure code is merged throughout the summer, and not delivered in a > big-bang patch at the end of the summer - history has shown us the latter > isn’t the right approach). > > I’ve got all the ideas so far up at > http://wiki.xmpp.org/web/Summer_of_Code_2015 > > /K > > > > On 13 Feb 2015, at 19:10, Kevin Smith wrote: > > > > A reminder that I need the ideas in this week if we’re going to do > anything about GSoC this year - so far I’ve only had ideas in from 2 1/2 > projects, and many more than that told me they were interested. > > > > Monday, please. > > > > /K > > > >> On 9 Feb 2015, at 10:59, Kevin Smith wrote: > >> > >> Hi folks, > >> Although we’ve not officially decided to apply to GSoC this year, we’ve > got a lot of interest from potential mentors so I’m going to go ahead and > ask people to supply me with ideas. Rather than going the traditional route > of editing a wiki page en masse, I’d like to triage the ideas to make sure > they’re fully fleshed out as the ideas page is a large part of what Google > use to determine the quality of our application. Anyone interested in > mentoring a project this year, please send me the details in the format > that follows. If you’re not sure what’s involved in being a mentor, please > be prepared to allow about an hour a day throughout the summer; there are > many resources online about good mentoring, e.g. > http://google-opensource.blogspot.co.uk/2011/04/dos-and-donts-of-google-summer-of-code_21.html > . Mentors should be in a senior position within the project they’re > mentoring (or approved by those that are), and have some experience of > teamleading/mentoring/management; if you’ve got ideas for your favourite > XMPP project but aren’t in a position to mentor yourself, please get in > touch with someone who could mentor, and have them send on the ideas > proposal to me. > >> > >> Ideas template: > >> “”” > >> Software Project: e.g. Swift, Prosody, ejabberd, Smack… > >> Software URL: e.g. http://swift.im > >> Software VCS URL: e.g. http://swift.im/git/ > >> Software Description: Assume people don’t know what your application > is, so e.g. Swift is an XMPP chat client meant to be user friendly, written > in … (a few lines describing the project and its ethos). > >> Title: Short and descriptive title, e.g. “Server-side message history > support" > >> Brief explanation: A short paragraph (A half dozen to a dozen sentences > or so) describing what’s involved in the project > >> Expected results: Some concrete deliverables > >> Knowledge Prerequisite: e.g. extensive C++ knowledge, TLS > implementations > >> Implementation Languages: e.g. C++, Python, Javascript > >> Mentor: you > >> Contact details: MUC / IRC channel / mailing list etc. > >> “”” > >> > >> We don’t have much time to do this, so I’d like all the ideas in this > week, please. > >> > >> We also need teaser tasks, which I’d like to set up centrally this > year. I’ll send a mail about that once I’ve sorted out a sensible template > for them. > >> > >> /K > > > > -- Simon Tennant | CEO Buddycloud <http://buddycloud.com> | +49 17 8545 0880
Re: [Standards] MUC 2
On 12 February 2015 at 17:19, Dave Cridland wrote: > > On 12 Feb 2015 14:00, "Christian Schudt" wrote: > > > > Dave, maybe could you (or somebody else) elaborate on the "shortcomings" > and the "different demands of things like buddycloud" you have discussed > for those who didn't attend the summit. > > > > Also what's so bad about multiple parties chatting via a third party > chat service (your 2nd use case)? > > > > In the case of a private conversation between three people, it feels wrung > to introduce a fourth. > Agreed. They can join but don't get access to the "mentioned in confidence" history before they joined. Google Hangouts is very sensible about the two-people -> now-a-group upgrade handling. > Secondly, I think that we do want to maintain basic protocol compatibility > with old MUC, so clients joining via presence we probably want to support, > and clients sending messages would be unchanged. > Presumably this could be achieved through a translat-o-matic ( http://wiki.xmpp.org/web/Summer_of_Code_2015#MUC_to_Channels_translat-o-matic ) My vision is that legacy MUC clients can still work. But more modern BC clients can handle the case of liking a comment ( http://xmpp.org/extensions/inbox/buddycloud-channels.html#item-rating), comment threading, post revocation etc. S. -- Simon Tennant | CEO Buddycloud <http://buddycloud.com> | +49 17 8545 0880
Re: [Standards] XMPP or NodeJS ?
Hi Kwaye, On 17 December 2014 at 10:31, Kevin Smith wrote: > > On 17 Dec 2014, at 09:06, kwaye kant wrote: > > Thanks Cramer, > So I can not implement the node-xmpp-server and try to connect to with a > Java code line. Because the node-xmpp-server does not expose its services > to consume as a webservice. I think I can understand from now why my mate > couldn't argue a lot :) > Let me have a look on the ready-to-go servers list. > > Have a look at XMPP-ftw <https://xmpp-ftw.jit.su/> framework from Lloyd Watkin. XMPP-ftw sits between your XMPP server and web-browser. Your XMPP server takes care of all the message routing, and XMPP-ftw (written in node) takes care of massaging the XMPP messages into something more browser-friendly: XMPP-in, JSON bits out. Which makes for fast prototyping of messaging apps. Hope that helps. S. -- Simon Tennant | CEO Buddycloud <http://buddycloud.com> | +49 17 8545 0880
Re: [Standards] Veto on "Privileged Entity"
> > - we (developers of "Salut à Toi", http://www.salut-a-toi.org) an a few > other projects (namely Movim http://movim.eu, Jappix http://www.jappix.org) > or developers (notabily Sergey Dobrov is working on these issues too) are > working on an XMPP based decentralized (micro)blogging platforms. > Buddycloud is doing something similar, but seems to stick less on standard > XMPP in favor of proprietary extensions (Dave I know you're working on > Buddycloud, correct me if I'm wrong) > Buddycloud's approach is to keep application logic outside the XMPP server. Buddycloud runs as a component [and adapts XEP-0060's machine-to-machine semantics for "human-to-human"]. If Not sure what you mean about not being "standard xmpp"? S. -- Simon Tennant | CEO Buddycloud <http://buddycloud.com> | +49 17 8545 0880
Re: [Standards] [buddycloud-dev] XEP-0060 and mark read up to point.
Thinking about how a client will usually work, - you start off with a fetch-subscriptions, - then fetch new posts. So a different approach could be to do a 'fetch subscriptions' and read-up-to-enabled-pubsub server will then also return a 'read-state'. eg: and at client-defined intervals a stanza is sent to the pubsub server with Or? S. On 29 July 2014 10:31, edhelas wrote: > Why make it difficult when you can make it simple ? > > We could create a new XEP by looking how the IMAP protocol works. Each > subscribed user of a node can send a little "read" stanza to the server. > Then the next time eh will request the items of the the node, the server > can add a little tag to show him that this content has already been read. > > We can also add specific stanza like : > - Mark all read > - Mark read until this specific date > > But this should be resolved server side and I personnaly dont like the > idea to track these data with an another node, we will have serious > consistancy issues (like we already have with the Bookmark XEP). > > edhelas > > > On lun., juil. 28, 2014 at 7:18 , Ashley Ward > wrote: > > On 28 Jul 2014, at 18:14, Simon Tennant wrote: > > IMHO this is something that should be solved in that node rather than > running parallel nodes or adding a PEP dependency. Almost like returning a > different metadata key-value pair to each requesting JID. > > Now you mention it, it feels like it’s actually metadata on the > subscription (rather than the node), so perhaps storing it in the > subscription configuration might be more appropriate? — Ash > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] [buddycloud-dev] XEP-0060 and mark read up to point.
IMHO this is something that should be solved in that node rather than running parallel nodes or adding a PEP dependency. Almost like returning a different metadata key-value pair to each requesting JID. I remember Kev having some very wise ideas about how to elegantly solve this during the FOSDEM bus trip back to A-loft (but that could have been the beer speaking). S. On 28 July 2014 15:14, Ashley Ward wrote: > On 28 Jul 2014, at 14:06, Simon Tennant wrote: > > For buddycloud channels, we're looking for a sensible way to store a users > read state per publish-subscribe node. > > For example: > >- a pub-sub node has a large number of posts >- user reads some of them from oldest to newest on one device >- client stores "read up to this postID/timestamp" on pub-sub server. >- user carries on unread posts on a second device. > > In this case we're simply trying to store a timestamp/or postID of the > newest message that the user has read up to (vs IMAP style un/read per > post). > > Is there a sensible way to implement this per node, per user? > > > How about on a PEP node for the user? Although this is then taking it out > of the buddycloud stack. > > Alternatively, to keep it within the buddycloud stack you could store it > on a separate node within the user’s personal channels: > > e.g. > /user/u...@domain.com/readstatus > or something like that > > You could use the node id as the item id (for easy retrieval) and some > information within the payload (such as last item id read, when it was > read, maybe even what device it was read from). > > — > Ash > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
[Standards] XEP-0060 and mark read up to point.
For buddycloud channels, we're looking for a sensible way to store a users read state per publish-subscribe node. For example: - a pub-sub node has a large number of posts - user reads some of them from oldest to newest on one device - client stores "read up to this postID/timestamp" on pub-sub server. - user carries on unread posts on a second device. In this case we're simply trying to store a timestamp/or postID of the newest message that the user has read up to (vs IMAP style un/read per post). Is there a sensible way to implement this per node, per user? S. -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
Sorry about the confusion with the build. I should have doubled checked that before submitting. The SRV stuff was updated to use PTR records after the discussion in the XSF muc late last year. Hopefully clearer: http://buddycloud.github.io/buddycloud-xep/#DISCOthenDNS On 28 April 2014 22:53, Edwin Mons wrote: > On 28/04/14 18:11, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Buddycloud Channels > > > > Abstract: This document describes a profile and conventions for usage > > of the PubSub protocol in the context of a new > type of communication. > > > > URL: http://xmpp.org/extensions/inbox/buddycloud-channels.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > > > > Does para 3.2 imply that you should always do the DNS lookup, or should > a client that tries to find a Buddycloud pubsub domain only try this as > a fallback mechanism? If the former, why do the disco#info at all if an > SRV record is found? If the latter, how could the results be conflicting? > > Edwin > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] deprecating in-band registration
IBR is very useful. But many people expose it to the open world where it's open to abuse. IMHO, IBR is very useful when you are using a service like xmpp-ftw and need a way to create new users. In this situation IBR is only exposed on localhost and the web-bits, to the outside world. S. On 2 April 2014 09:36, Tomasz Sterna wrote: > Dnia 2014-04-01, wto o godzinie 21:01 -0600, Peter Saint-Andre pisze: > > I suggest that we push this line of thinking to its logical conclusion > > and strongly consider deprecating and then obsoleting IBR. [...] > > If we feel that we'd like to have some kind of method for account > > provisioning over XMPP - and I'm not convinced that we do - then I > > feel that we need to rethink the whole problem, [...] > > We have this notion of obsoleting existing protocols without providing > alternatives. > People do not like this approach and I've been defending XMPP over the > years, but to this, I have no answer. > Hell... I don't like this approach. > > IMO the correct order is: > 1. Do we want to obsolete IBB or maybe fix its issues? > 2. If we want to obsolete, we need to design its replacement. >It's easy now, since we identified its deficiencies in 1. > 3. Propose replacement for IBB and test-drive it. > 4. Obsolete IBB. > > > -- > Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/ > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
[Standards] Buddycloud XEP
It would be really useful if to have some more eyes on the Buddycloud XEP before submission. http://buddycloud.github.io/buddycloud-xep/ Any feedback here or https://github.com/buddycloud/buddycloud-xep/issues?state=open would be really appreciated. @Cridland: thanks for your help the other day. S. -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] SMS/Email Forwarding of Messages
IMHO this is really something that should be in the push spec. - configure with numbers/email addresses - push events to "pusher component" Services like "knowing if delivery has gone through could be reflected in the to . This is how we solved it on the Buddycloud "pusher" https://github.com/buddycloud/buddycloud-pusher#add-or-configure-push-records @Lance - do you need any help writing the XEP once you are finished with Websockets and London? ᐧ On 17 February 2014 15:02, Spencer MacDonald < spencer.macdonald.ot...@gmail.com> wrote: > Hi Steffen, > > I was at the summit and also thought that it could be added to the push > notification XEP, but for SMS/Email you might want to: > > - Know what telephone number or email address the message was forwarded on > to. > - Know if the message has been sent/received/opened > - Opt in/Out of paying for forwarding (in the case of SMS). > > So although it can be just another end point, I think you still need > additional logic when compared to push notifications. > > Regards > > Spencer > > On 17 Feb 2014, at 13:51, Steffen Larsen wrote: > > > I think you might look at the stuff we were discussing at the XMPP > summit, namely push notifications. > > Lance stout have begun doing a XEP for this: > http://legastero.github.io/customxeps/extensions/push.html > > > > It can prob. be used for SMS and email as well. Just another endpoint. > :-) > > > > /Steffen > > > > > > On 17 Feb 2014, at 14:47, Spencer MacDonald < > spencer.macdonald.ot...@gmail.com> wrote: > > > >> Is there any XEP that covers a message getting forwarded using another > transport e.g. SMS, Email? > >> > >> If not would there be any interest in making a standard one? > >> > >> My personal use case is if the recipient is offline, the message can be > forward to their phone as an SMS. > >> > >> Regards > >> > >> Spencer > > > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Push notification XEP
We're going to be switching the Buddycloud-pusher to the XEP and making it as standards compliant as possible. Right now it Pushes to Android and Email: https://github.com/buddycloud/buddycloud-pusher/blob/master/README.md#component-design. We're using it in production already and it "just works". Code is all on github. S. On 2 February 2014 15:16, Adán Sánchez de Pedro Crespo wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > So do I! > > I'm eager for seeing this move forward and start making > experimental/reference implementations. You can count on a strophe > client plugin and prosody server one ;) > > > Regards, > - -- > *Adán Sánchez de Pedro Crespo* > /FLOSS Developer at Waaltcom/ > PGP Public Key: CCABF8A0 > Cel.: +34 663 163 375 > Fix.: +34 912 69 22 00 > PLN: +00 4200 > VoIP: 2...@sip.waalt.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJS7lNQAAoJEOKCghY7/+mkvaEIAJ6REShFrifFBhOcAMaoTpLq > msau0/fUXo8Py3XXwmR1D0lcWc/IaaPPjqyooc/SYf4UHUaADj8FR4UX6VFDnN0B > /YzamgM7//p+8DJsSJ1zga58qlJmiFEn0xFsPNZdvgawKtfE1wlRgn+ztwdQnWGf > 1cLJ5leunUToEmXNWnvZOZ6M+/NUahsVpccbiv9r8dBBtV2hN5bYm3UwsTwmWUtU > kT1rln3gzXVWmFVIpAUyHLCQqujPZ0w0dwdv006pPX4IQCwKUyn8e+gel7bTZB4/ > hF6Hovnxa/3FA1okE823HWjAk+V8xbHT+z+lkqqiXs5tRH9Ht41P5pqKj0D6dq0= > =AXuq > -END PGP SIGNATURE- > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
[Standards] Push notifications
Interesting conversations about push today. This is how we do it (curently) at buddycloud to send "someone followed you" "new posts in your channel" etc. https://github.com/buddycloud/buddycloud-pusher/blob/master/README.md Keen to standardise. S. -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Discussions at the summit
Added. Looking forward to resolving Push Notifications and getting it XEP'd. S. On 27 January 2014 12:01, Spencer MacDonald < spencer.macdonald.ot...@gmail.com> wrote: > I assume only certain people can edit the page (or I missed the button)? > > It would be good to add: > >- Push Notification XEP >- Stanza Throttling/Buffering > > > Both of which has been discussed on the list, but didn’t reach a > conclusion. > > Regards > > Spencer > > On 27 Jan 2014, at 10:42, Kevin Smith wrote: > > Hi folks, > Just a quick reminder for those attending the summit. If there are > things you'd like to have on the agenda, please pop them on > http://wiki.xmpp.org/web/Summit_15#Agenda - and if everyone can have a > look at what's there before going and work out what stuff you > particularly want to be involved in discussions for it should make > planning the agenda when we get there much faster and easier. > > Ta, > /K > > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Push notification XEP
The Buddycloud pusher approach is - Run as a component - be generic: don't care about the specific push service (email, Google, Apple, next-big-thing) - Give users a way to enable/disable it - Advertise it as a service using SRV records (virtual host for other domains that don't want to run a full push service) Would be nice to think about how push notifications could work with some of the SIFT specs. Eg: a new would trigger a push, wake an Android App, sync, kill connection, go back to not keeping an open connection. Daniele - will you be at the Summit? S. On 21 January 2014 11:53, Steffen Larsen wrote: > Yes but the approach that this bodycloud component (XEP-0114) could easily > be written into more or less a XEP. > > /Steffen > > On 21 Jan 2014, at 11:51, Daniele Ricci wrote: > > > I was thinking of a more specific (and simpler) approach to just using > > push notification services. Buddycloud is much more than that. > > > > On Tue, Jan 21, 2014 at 11:30 AM, Abmar Barros > wrote: > >> It sounds like what we've been doing with the buddycloud pusher: > >> https://github.com/buddycloud/buddycloud-pusher. > >> > >> We currently use it to send GCM and emails regarding buddycloud-related > >> events, as per its documentation, but it can be easily extended to push > any > >> XMPP event to any pusher service, eg.: Apple's, SMS. > >> > >> Regards, > >> Abmar > >> > >> > >> On Tue, Jan 21, 2014 at 7:58 AM, Daniele Ricci < > daniele.ath...@gmail.com> > >> wrote: > >>> > >>> Hello list, > >>> I was thinking of writing a XEP for sending a sender ID (Google Cloud > >>> Messaging) or a device token (Apple Push Notification Service) or any > >>> other push notification service token (that is, a generic one) to the > >>> server. > >>> Almost all push notification services works the same way: the server > >>> provides a provider ID to the client and the client provides a device > >>> token to the server. > >>> > >>> I was thinking of using service discovery to advertise the service > >>> from a server: > >>> > >>> > >>> >>> node='http://jabber.org/extensions/presence#push'> > >>> > >>> > >>> > >>> > >>> > >>> > >>> In the "node" attribute I'd put the provider ID I was talking about > >>> earlier. > >>> > >>> Device token could be sent using a presence update from the client: > >>> > >>> > >>> ... > >>> ... > >>> REGISTRATION-ID > >>> > >>> > >>> (that would need to be filtered by the server before broadcasting the > >>> presence update though, for security reasons). > >>> > >>> Or an iq to the push notification address could be used: > >>> > >>> > >>> >>> xmlns='http://jabber.org/extensions/presence#push > '>DEVICE-TOKEN > >>> > >>> > >>> I'd really appreciate some feedback. I think it would be a useful XEP. > >>> Regards, > >>> -- > >>> Daniele > >> > >> > >> > >> > >> -- > >> Abmar Barros > >> MSc in Computer Science from the Federal University of Campina Grande - > >> www.ufcg.edu.br > >> OurGrid Team Leader - www.ourgrid.org > >> Buddycloud Dev - www.buddycloud.org > >> Paraíba - Brazil > > > > > > > > -- > > Daniele > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP
IMHO, e2e security would probably make more sense as a XEP and working group that has the time to zoom into all the implementation details. S. On 18 November 2013 10:30, Andreas Kuckartz wrote: > Peter Saint-Andre some time ago wrote: > > On 7/16/13 4:27 AM, Carlo v. Loesch wrote: > >> Since XMPP isn't suitable for keeping meta-data private I would > >> presume that e2e privacy is out of scope for this mailing list, > >> really. > > > > True. > > Where would the topic e2e privacy for XMPP be "in scope" ? > > Cheers, > Andreas > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Proposal: Public Key pinning
On 12 November 2013 00:33, Thijs Alkemade wrote: > * DANE. DNSSEC deployment is still low and DANE is low compared to that. > Few > DNS stacks include support for DNSSEC, so widespread DANE deployment is > unlikely to happen soon. > I would love to have a guide on how to setup DANE and DNSSEC for an XMPP server. And have a primer added to the http://wiki.xmpp.org/web/Securing_XMPP#Prosody_.28secure_delegation_with_DANE.29page. Has anyone managed to do this? Would anyone have time to walk me through setting this up and I'll write up a recipe. S. -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Re-escalating update of XEP-0313: MAM
Also, expanding Spencer's point, > other clients connected to the account would also need to be notified > of the deletion - and they might be offline at the time. > What about exposing the archive as a pub-sub node? That would take care of notifications and resyncing etc. S. -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Upcoming Summit 14
I'd like to talk about WebRTC setup negotiation on pubsub nodes so that we can get this baked into buddycloud. And talk more about how we work to a secure-by-default model for S2S. And drink a few beers. S. On 25 September 2013 14:17, Matthew Wild wrote: > On 25 September 2013 12:09, Dave Cridland wrote: > > I don't think there's any specific issues I'm poring over with XMPP > > currently. There's no contentious issues in XEPs, or IETF I-Ds, that I'm > > feeling particularly anxious about. > > Jingle? :) > > > Besides, the most productive Summit discussions are often about the more > > general topics, I suspect. Since this year seems to have been dominated > by > > dragnet style surveillance tactics, and security in general, I wondered > if > > we might be able to devote some time to a general round-table discussion > of > > the area. > > +1. I think there has been surprisingly little discussion about this > in the XMPP community, considering it's been (being) discussed to > death everywhere else. > > > I think overviews of where we are with POSH et al would also help, > > but also how the security landscape as a whole has changed - I know I've > > largely changed my opinion on the benefits of anonymous encryption, for > > example. > > I'd love to hear more about that. > > > If there's interest, it might be as well to also schedule an online > > discussion in a chatroom - in part because I suspect mixing remote and > local > > participation in a general and largely unstructured chat won't be very > > effective. > > Sounds fine to me. Here's an idea: we could have such a meeting > monthly, discussing a different topic each month. > > Regards, > Matthew > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] jabber-id email header
Not sure what this JabberID thing is Has anyone thought of putting your XMPP-ID into an email header? Now that would be awesome! S. On 20 September 2013 17:12, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 9/20/13 8:25 AM, Alexey Melnikov wrote: >> On 20/09/2013 03:44, Peter Saint-Andre wrote: >> >>> Back in 2007 we defined an email header for advertising your >>> Jabber ID in your email messages: >>> >>> http://tools.ietf.org/id/draft-saintandre-jabberid-08.txt >>> >>> For various reasons we never got this header registered with >>> IANA, but on re-reading RFC 3864 I've concluded that we could add >>> it to the provisional register through a XEP instead of an RFC. >> Can you do an Independent submission to RFC Editor? You already >> have a draft... > > Now that I think about it, I might resurrect this as an I-D and get it > published as an RFC. I last pursued this back in 2007 when everyone > (well, some influential people at the IETF) thought that the world > would switch to using 'im:' and 'pres:' URIs. That hasn't exactly > happened. :-) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSPGXmAAoJEOoGpJErxa2pSXcQAJ8AXKNfP9fxRv6Yi7Ohr9r0 > g805cRvlAvd+ehdIhuqodr8B6MCLZFHzmZqRWpJtmvf+ZKGD1+Ja7xc8PcqYALez > vX/HV1RrUEpzmr97lslXufDXtKzP3DLfU8G7/psF4IpeCaDdWCukOVXzP99VNGw+ > +4QwTGvri9UVvlwnUOf+CX2qegxMdFFQ/pImYrm0fI82zs28+ebgx5G4/AsldsEN > HZgqIZXyzrBfECFnosvwagc+vEsLGCp1mWm9Yoys/EdCOK+X+bokecquiDanwnvo > PIl8JA4PQHRvzTQcu3F/a68iHajqsBspdbzZ5E5SSJddEySDNG0ZYaXaRuidDHbF > 6BeHyxvTwtVH/g/7sS9e3A7r7mVSU+glohF3nNmcgU9N6p9JlCmI/ipZ7CBqU0x2 > kT+h3YvnoMHJAanU6plNmVoZohWlIa6fO/bJZXYDNxf82fLCP+3ECuW24V9jfUc6 > dwR7ghfyD4CNK6HRA+TyWjibgOqRFqifhYTP2UvBwHg/RZBodbNN9uYIc3DzZr6K > k+qeqP729n6Z7Anv02bOkR6tmWFPNWx22/+89+1t8oQrt1/vy4Jc/n2jslegmJvA > U2JhjweYJxd7dz/phQHIGBs+Pe2HLCF3UsxxKl00YpDy1+wsLWiYHGSVHpObMlRd > JomTihLmN6QuPiH94Zuj > =Dn5j > -END PGP SIGNATURE- -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] XEP-0084: User Avatar and Different Sized Images
I read in the spec that: *It is intended that this specification will supersede both IQ-Based Avatars<http://xmpp.org/extensions/xep-0008.html>[ 6 <http://xmpp.org/extensions/xep-0084.html#nt-id208472>] and vCard-Based Avatars <http://xmpp.org/extensions/xep-0153.html> [7<http://xmpp.org/extensions/xep-0084.html#nt-id208494>] once the PEP subset of XMPP publish-subscribe is implemented and deployed widely enough.* One of the reasons I never turn on vCard support for servers is that it opens up a can of worms - - a user fills out their vCard or edits their Avatar and drags over a photo of themselves that is 7MB. - another user's phone client is now stuck trying to download a huge image - likewise, as a server admin I can't set an upper bound on the image size. S. On 24 July 2013 11:16, Spencer MacDonald wrote: > Hi, > > I was wondering if it is "allowed" to have multiple sized images (width > and height) in a single node? e.g. a thumbnail and full scale image. > > Section 5 of the XEP specifies that you can have different formats, but I > want to have the same format but at different sizes. > > Regards > > Spencer > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] HTTP over XMPP - new revision
How does this deal with web pages larger than 64K? What's the intended use for this? I mean it's cute and nice, but it smells a lot like reinventing the wheel. S. On 18 June 2013 13:49, Joachim Lindborg wrote: > This is now accessible in the dropbox with XML,XSD files, > https://github.com/joachimlindborg/XMPP-Web3 > > /Joachim Lindborg > > 2013/6/18 Peter Waher > >> Hello everybody. >> >> ** ** >> >> I’ve now created a new revision of the HTTP over XMPP XEP proposal >> according to all major comments and suggestions provided to me: >> >> ** ** >> >> **· **The streamBase64 transfer mechanism has been removed and >> replaced by in-band byte streams. >> >> **· **Examples have been remade so that public examples are not >> reused or linked to. (Examples available in other XEPs are still present >> however.) >> >> **· **Transfer mechanism descriptions have been extended. >> Special emphasis has been made to describe the differences between options >> that might look similar to some readers. >> >> **· **The client can now provide client capabilities in the HTTP >> request header, permitting partial implementations of the specification.* >> *** >> >> ** ** >> >> The schema has been updated to reflect these changes. >> >> ** ** >> >> If you have any comments or questions, please let me know. >> >> ** ** >> >> Sincerely, >> >> Peter Waher >> > > > > -- > Regards > > Joachim Lindborg > CTO, systems architect > > Sustainable Innovation AB > Adress: Box 55998 102 16 Stockholm > Besöksadress: Storgatan 31 (Malmgården) > Email: joachim.lindb...@sust.se, www.sust.se > linkedin: http://www.linkedin.com/in/joachimlindborg > Tel +46 706-442270 > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] resurrecting Hop Check (XEP-0219)
End to end encryption is a worth goal. This is very cool for getting
information on the s2s connection.
XEP-0219 makes a lot of assumptions about the network topology always
involving the traditional c2s design.
How might this XEP report meaningful information back to the user in the
following situations:
- cleartext BOSH inside SSL terminated HTTP session?
- cleartext on loopback to new c2s services like XMPP-FTW or the
buddycloud-api?
- websockets?
S.
On 6 June 2013 09:56, Dave Cridland wrote:
> On Thu, Jun 6, 2013 at 6:11 AM, Philipp Hancke
> wrote:
>
>> I've been thinking I'd like to resurrect the Hop Check proposal
>>> (because after further reflection I think it would be useful, even if
>>> not perfect):
>>>
>>
>> for debugging/support? +1
>>
>>
> I've not checked back to see whether I liked this or not before, so I
> don't know whether now deciding it'd be a good thing would be an
> embarrassing U-Turn or not...
>
> But FWIW, when this was proposed, I think it was suggested as a "is my
> end-to-end path secure?" - to which the answer is "not if you had to ask" -
> rather than as a debugging protocol.
>
>
>> [...]
>>
>> Before I post an updated version, does anyone have requests for data
>>> they'd like to see included in the data format?
>>>
>>
>> A bidi flag (for s2s) and the raw certificate data for both dialback and
>> external auth. Probably also whether an SRV record was resolved or the A
>> fallback is used.
>>
>> And keep in mind that most s2s connections still aren't bidi, see the
>> list archives from 2007 for some discussion ;-)
>>
>
> 1) I'd suggest for most things we just stuff features into the thing if
> they've been used, maybe?
>
> So for XEP-0138, we'd see something like:
>
>
>
>
>
> This'd hold for SASL auth, too:
>
>
>
>
>
>
>
> 2) I know that having the certificate chain would also be useful, as well
> as any reasoning for trusting it - or not trusting it, perhaps even more
> important. There are many times I'd have dearly loved to have been able to
> tell why a certificate wasn't trusted by the peer in ways that didn't
> involve trying to parse other people's logs, so the reasoning here is more
> useful that the certificate chain to me.
>
> 3) I'd also point out that while it'd be very useful to know how your
> victim authenticates, having this as a mandatory feature seems like a
> security issue. ("Oh, he authenticates using PLAIN without TLS, does he?
> Oh, goody!")
>
> 4) Some links - S2S, for instance - have have different characteristics on
> the return path than the forward path - XEP-0219 never addressed this. I've
> a feeling this one came up at the time.
>
> 5) Currently, this protocol is framed such that each hop is mandated to
> ask the next. It might be useful for this to be reframed as an end-to-end
> protocol, so that Juliet asks her server, then Juliet asks Romeo's server,
> then (possibly) Juliet asks Romeo.
>
> So, erm, basically that's close to a complete rewrite, I think. :-)
>
> Dave.
>
--
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP
Re: [Standards] Proposed XMPP Extension: HTTP over XMPP transport
1. Collect $2000 per member 2. buy .lit TLD ... 4. $$$ profit? My next grumpy-old-man comment is the residual use of "Jabber" in the specs. I'd love to submit a pull request in to fix this (via Github). S. On 7 May 2013 20:31, Peter Saint-Andre wrote: > On 5/7/13 12:18 PM, Simon Tennant wrote: > > My point is that it's a bit weird for a standards organisation to be > > pointing at someone else's domain. Unless of course capulet.com > > <http://capulet.com> and montague.net <http://montague.net> are > > registered and reserved by the XSF. > > That's why I typically use domains with .lit -- but with the TLD > expansion those won't be safe either. (Some of the old specs used things > like capulet.com and montague.net, and we haven't cleaned them.) > > Peter > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Proposed XMPP Extension: HTTP over XMPP transport
My point is that it's a bit weird for a standards organisation to be pointing at someone else's domain. Unless of course capulet.com and montague.net are registered and reserved by the XSF. On 7 May 2013 19:56, Peter Saint-Andre wrote: > On 5/7/13 11:49 AM, Dave Cridland wrote: > > Don't these headers and shim have different semantic meaning, though? > > Not that I can see. Care to elaborate? > > Peter > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Proposed XMPP Extension: HTTP over XMPP transport
Can we also please start using reseved for documentation example.com/org/netfor domains in examples. http://en.wikipedia.org/wiki/Example.com S. On 7 May 2013 16:10, Peter Saint-Andre wrote: > On 5/7/13 8:07 AM, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: HTTP over XMPP transport > > > > Abstract: This specification defines how XMPP can be used to transport > HTTP communication over peer-to-peer networks. > > > > URL: http://xmpp.org/extensions/inbox/http-over-xmpp.html > > I'm not yet convinced of the need for this extension, but if we're going > to proceed with it then I strongly recommend re-using the syntax from > XEP-0131. > > Thus... > > OLD > >from='httpcli...@clayster.com/browser' >to='httpser...@clayster.com' >id='1'> >version='1.1'> > > > > >from='httpser...@clayster.com' >to='httpcli...@clayster.com/browser' >id='1'> >statusMessage='OK'> > > > > > > > NEW > >from='httpcli...@clayster.com/browser' >to='httpser...@clayster.com' >id='1'> >version='1.1'> > > clayster.com > > > > >from='httpser...@clayster.com' >to='httpcli...@clayster.com/browser' >id='1'> >statusMessage='OK'> > > Fri, 03 May 2013 13:52:10 GMT-4 > OPTIONS, GET, HEAD, POST, PUT, DELETE, > TRACE > 0 > > > > > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] Commenting: XEP-0277 and XEP-0303
r the second item I have prepared the XEP-0315. It's experimental and > I don't know if it's possible to link XEP-0060 to an experimental XEP > but the problem is that this XEP is not useful anywhere else, so it > won't quit the experimental status otherwise. I have sent to Peter my > edits to XEP-0060 that uses XEP-0315 to serve node metadata but did not > receive any answer. Don't sure if Peter has received it at all. > > Also, a long time ago I have sent a letter to this list where specified > that 7.1.2.3 "Item Publisher" section is unclear in XEP-0060 and it's > impossible to know if the pubsub service will send stanzas with > publisher attribute. There is no any suitable solution yet. > > I have more, but should I post them here? :) I did it many times... > > > > > Cheers > > Goffi > > > > On my experimental component, I'm not using PEP because as far as I know > it's > > not possible to have an external PEP componant. But I think an external > PubSub > > componant is important: it's not tied to a server implementation, and we > can > > implement what we need to try the experimental XEPs or other ideas. > That's why > > I have requested an update on RemoteRoster proto XEP. > > > > > Yes, I agree here, and the forth item was a subject to discuss here a > long time ago too. > > > -- > With best regards, > Sergey Dobrov, > XMPP Developer and JRuDevels.org founder. > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] PEP - Public PubSub subscribed list
I understand that you want to do lookup in PEP. I'd be very wary of depending on it to build a full scaled social platform. We tried using PEP to build buddycloud. We created a bunch of nodes for each and would push out updates based on presence. This kinda worked with the following caveats:: - it was server specific (any changes to PEP had to be made to each server)/you loose the portability of XMPP components - scaling and performance (this could have been an issue with ejabberd at the time). - difficult to build any extra business logic into PEP. For example:"this set of users can reply to my posts" I think that the OneSocialWeb guys ran into similar issues with their PEP-based service. Our XMPP architecture for buddycloud has shifted: build as much as possible outside of the XMPP server core. We use components to scale out services and use the XMPP server just as a router (the famous "xmpp middleware" topic). The benefit of using components for your service is that running Movim will have the ability to switch out their XMPP server as their needs change. One solution that might give you some milage: using DISCO to point to a pub sub component that is nominated for social activities? (Something like https ://buddycloud.org/wiki/XMPP_XEP#buddycloud_Server_Discovery). This will give you much more flexibility in the future and nto tie your solution to a particular XMPP server vendor. S. On 12 February 2013 07:28, Sergey Dobrov wrote: > On 02/12/2013 01:29 AM, Jaussoin Timothée wrote: > > The user's server could track all their subscriptions, but this would be > > prone to errors and would necessitate their server understanding pubsub > to > > some extent. > What errors? Unfortunately, with PEP server must understand pubsub > anyway so I don't see the problem to track user's subscribe requests > too. Another question is that it would be nice to have a way to write > stand alone PEP services to increase their quality. But it's completely > different question. > > -- > With best regards, > Sergey Dobrov, > XMPP Developer and JRuDevels.org founder. > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] PEP - Public PubSub subscribed list
At buddycloud we store your channel subscriptions on the pubsub server. It looks like Movim needs pub-sub anyway. Just stick everything in to pubsub - this will save you needing servers with PEP. On 10 February 2013 16:08, Jaussoin Timothée wrote: > Le 08/02/2013 08:48, Tim a écrit : > > Hi everyone, >> >> We are working, on our project, on a PubSub implementation. Our aim is >> to offer a more "social-network" view of the XMPP protocol, and PubSub >> is, for us, a way to add a "Group-like" feature to our users. >> >> PubSub gives us what we want. But XMPP users doesn't have the >> possibility to share with to their contacts some of the PubSub nodes >> they have subscribed with. >> The idea here is to use PEP to store a list of pubsub nodes and >> allowing a user to notify its contacts when he wants to share some of >> theses. >> >> The stanza might look at this : >> >> > from='u...@server.tld' >> id='1'> >>> xmlns='http://jabber.org/**protocol/pubsub<http://jabber.org/protocol/pubsub> >> '> >> >> >> >> >> >> >> >> >> >> What do you think of this? >> >> Jaussoin Timothée aka edhelas, The Movim Project (http://movim.eu/) >> > No comments to make here? > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP
Re: [Standards] File hosting XEP?
> > Yes, sorry, you're right. I just meant that buddycloud invents it's own > protocols instead of edit existent XEPs, write new, with an XMPP > community participation. It's a valid approach but differs from mine. > Ok I'll bite. buddycloud is built on pub-sub and federates using XMPP. buddycloud designs social software to power millions of users using open-source, open protocols and provides great reference implementations. To do this we have two choices: 1. deploy a XEP-0060 pub-sub server and hope that uses suddenly find it useful even through it was really designed for machine to machine communication. Now you have to force users to start using it. And they don't. 2. Or, look at what users really want, try and adapt standard so that developers can use existing design fundamentals and existing libraries and match these up with your users' real-world needs. So, I agree - buddycloud isn't pure XEP-0060 and that's totally fine by me. My mom cares about communicating, not XEP-0060 and there's a lot more "my moms" out there than developers than developers sitting aroudn the spec campfire. Developers care about being able to pick up a pub-sub library and build. To me that's a win for both parties. Following on from this (and we're getting closer to this point now) when the protocol kinks have been worked out, we loop back and plough that learning into a spec (we're tracking our pub-sub adaptions here: https://buddycloud.org/wiki/XMPP_XEP). tl;dr: writing a spec first without real users and a real product means your spec will sit on a shelf gathering dust. S. -- Simon Tennant | buddycloud.com | +49 17 8545 0880
Re: [Standards] Microblogging: XEP-0277 and beyond
It's my understanding of the XEP process that we standardise ways of doing something so that many clients and servers can interoperate. And for machine to machine services this is easy: machines do as we say and interoperate as we say. It's a predictable environment. Social is not easy and neither are user and groups of users predictable. Additionally, social services built on XMPP will have different business logic and be built into different applications in different ways. Getting this business-logic right will depend on the problem being solved. That's why I like XEP-0277; it says all one can really say about social (summary of XEP-0277: use atom for posts and post to a pub-sub like node). We all want interoperation between services. Social is different for different products: what works for one kind of use case will not work for someone else: some people think it should be roster based with groups like Google circles. Others want it decoupled from the roster. Some people want to add code to XMPP servers, others build pub-sub solutions. Some services have a single poster model, others are more like MUC with many posters. To help make this conversation go forward we need a solid description of what is being offered to the user. These are the questions we need to answer before we try to work out a spec(s): * the target user (hint: my parents won't be twiddling roster groups) * define the use case * how does it work? what happens when... (this is the social part) * clearly define the publishing and following models I am extremely doubtful that this process leads to a one-size-fits-all answer. And it would be a rather mediocre mishmash of kludges. I think a far more realistic result will be a couple of types of social services. Off the top of my head: * microblogging to pep nodes * twitter-like service * buddycloud-like service Each service (and hopefully spec) will relevant to a particular way of interacting and designed for a type of use case. It's really important that we avoid a rush to standardise that results in something mediocre and end up with the MySpace of the XMPP world: dropped after 2 years and filled with spam. XMPP gives us a huge advantage when building social services: its native federation and its built-in support for remote user-ids are awesome. Let's build awesome services for our users based off specs relevant for a particular use case. S. On 18/08/2011 16:47, Goffi wrote: > Le Jeudi 18 Août 2011 20:40:05, Sergey Dobrov a écrit : >> It's a bad idea to append the number to the namespace since it reserved >> for different revisions of XEP and not for your purpose. Again, I think >> that this should be solved by some privacy lists extension since your >> decision again restricted. > As I said before, it just a Q&D hack for testing purpose, I know it's not a > good solution. I would rather use privacy lists or whatever if we could have > a > per-item access management with it. > >>> If I have to poll this by myself at client side, I'll have to send X IQ >>> stanza for my X contacts, and flood the server. >> Client should cache data. You will flood anyway the only difference is >> who will flood: client or server. > In all cases the client will need the data, and it's better to send one > request to server, that X request for X contacts. > Actually I think about something similar to Extended Stanza Adressing > (http://xmpp.org/extensions/xep-0033.html), but to get several pubsub nodes > at > once. > > >>> I ask last items presence to not have to poll individually all my >>> contacts roster. On some blue centralised services, it's common to have >>> 100+ contacts, should I poll all of them each time I log-in ? >> No, Pubsub node can send you an event when you came online with the >> serial for it's journal so you can decide to ask the node for new items. > Oki, that looks like a nice solution, once again, waiting an answer from > pubsub people. > -- Simon Tennant mobile: +49 17 8545 0880 office: +49 89 4209 55854 office: +44 20 7043 6756 xmpp: si...@buddycloud.com build your own open and federated social network - http://open.buddycloud.com
Re: [Standards] microblogging maintainer :)
On 20/12/2010 19:01, Thomas Baquet wrote: Okay, so let's take the Atom way then: when a node allows a write access to user, it means he can post reply to items on it. But there stills a problem: imagine than - in a more general way - I post an blog article on my "blog" node; how will I manage wether people will effectively post a reply to this article or when they will post an article which is not a reply? For certain kind of content allowing people post in my node item which are not necesseraly item can be useful (like facebook wall), but others no. It would really help if we had some concrete examples of what features and use-cases this spec is trying to support? We all have different ideas of what micro-blogging means means and arbitrarily hammering out a spec without some predefined use cases and users stories is spec-masturbation: fun, but rather pointless. It may well be worth leaving this spec as nothing more than "publish to a node" (pep or pubsub) and "use atom payloads. Trying to define anything more than that, like the business logic of who can reply to what is really the role of an implementer and depends on the type of community they are building their application for. If people want to define more then implement an application and see how users use it and adjust accordingly. I would really like this stuff all standardised based on how buddycloud users have used channels, but even then I think that going more detailed is really constraining (and with little benefit). S. -- Simon Tennant mobile: +49 17 8545 0880 office: +49 89 4209 55854 office: +44 20 7043 6756 xmpp: si...@buddycloud.com build your own open and federated social network - http://open.buddycloud.com
[Standards] Reliable message delivery (XEP-0198 and XEP-0184)
More XMPP clients are being built to run on mobile networks. Message reliability on mobile clients has never been great and a good way to detect message loss and recover is very important. We need good server implementations of these specs. We are at the point where we may have competing specs. XEP-0198 and ProcessOne's TextOne subset specification. I'm aware that Prosody has an implementation of this and that M-Link has also been working on XEP-0198 support. Is there a way that we can avoid multiple implementations by addressing the Mickaël's issues https://support.process-one.net/browse/EJAB-532 (message replay, mixing of concepts)? I'm a firm believer in implementing something first and then writing a spec based on the learnings; could some of the existing implementers please comment on the perceived deficiencies of XEP-0198 and XEP-0184? Do parts of the spec need to change? What can we do to avoid competing XEPs? S. -- Simon Tennant mobile: +49 17 8545 0880 office: +44 20 7043 6756 office: +49 89 4209 55854 channel:http://buddycloud.com/user/buddycloud.com/simon xmpp:si...@buddycloud.com mailto:si...@buddycloud.com
Re: [Standards] LAST CALL: XEP-0255 (Location Query)
Yes. We had a little chat about this and will make edits to make it clearer. I expect we will have something back by the 15th June that better defines the scope of the XEP and points to anxillary XEPs where necessary. S. On 02/06/2010 06:27, Peter Saint-Andre wrote: Simon, do you think that changes to XEP-0255 are needed as a result of the Last Call? On 5/4/10 8:18 AM, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0255 (Location Query). Abstract: This specification defines an XMPP protocol extension for querying a compliant server or service for information about the geographical or physical location of an entity. URL: http://www.xmpp.org/extensions/xep-0255.html This Last Call begins today and shall end at the close of business on 2010-05-21. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Re: [Standards] LAST CALL: XEP-0255 (Location Query)
On 14/05/2010 06:15, Bernard Aboba wrote: Having gone through the (somewhat painful) process of editing RFC 3825bis (see http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis) and having to carefully delineate between the meaning of the terms "uncertainty" and "resolution", I would recommend that the authors think very carefully about the meaning of the term "accuracy" in this document. It's quite common for location-based systems to return the level of accuracy that they are able to calculate the position to. Could you be more specific about your accuracy concern? The other thing that strikes me about this document is that doesn't talk much about distinguishing between third party queries and a host querying for its own location. This distinction has a number of privacy implications and has led to quite a bit of angst within the GEOPRIV WG, as reflected in documents such as the HELD identity extensions document (see http://tools.ietf.org/htmldraft-ietf-geopriv-held-identity-extensions ). XEP-0255 is a method for a component or JID to send measurements to a server and receive back a calculated location. Just that. I have been following the HELD process closely and after reading it, I'm pleased to be working on XMPP instead. They have had to create privacy, distribution, authentication and trust mechanisms from scratch. XMPP provides privacy, distruibtion, authentication and trust for free (XEP-0060, XEP-0080 amongst others). If there is a reason to duplicate these functions then they should be included in XEP-0255. In my opinion, the XEP specification's great benefit is the ability to combine them together. XEP-0255 doesn't try to define how location must be shared. Some implementers may use PEP, others may prefer Pubsub or even stanzas. This really depends on the specifics of the application and in my opinion is not spec dependent. S.
Re: [Standards] XEP-0255 (Location Query)
Helge Timenes wrote: > That is a good idea. And also brings up an already asked question. Would it > be better to de-generalize the element into explicit , , > , and as suggested, elements? > > Pros/cons anyone? We will soon have WiMAX and then LTE-type cell-ids and... So let's not paint ourselves into a corner by presuming that all beacon types are accounted for. Please don't de-generalise. "type=" works well for this. IP is just another type of beacon. S. -- Simon Tennant Buddycloud uk: +44 20 7043 6756 de: +49 89 420 955 854 uk: +44 78 5335 6047 de: +49 17 8545 0880 email and xmpp: si...@buddycloud.com
Re: [Standards] [mobile] [Fwd: Proposed XMPP Extension: Location Query]
Stephen Pendleton wrote: > Very cool. > Question for the authors: Are you really using arc-minutes as units of the > GPS error or is that carryover from the GEOLOC XEP? Props should go to Helge for the spec. I guess that writing specifications for unmanned aerial vehicles is finally paying off. I presume you are referring to this post: http://mail.jabber.org/pipermail/standards/2008-October/019920.html Arc-minutes are a carry over. We wrote the spec with XEP-0080 in mind and use that as the format for publishing the derived location to the user's geoloc node too. We would prefer to use accuracy in meters. While arc minutes may make sense in a GPS sense, accuracy often has to be implied when using other location means. For example, if the server is receiving Cell-ID beacons and some of the known beacons are identified as within a city an accuracy of 100m could be implied due to a known higher tower density. Trying to apply arc-minutes to this would probably end up just being clumsy and it would be nice to use the same unit of measurement for accuracy. S. -- Simon Tennant Buddycloud uk: +44 20 7043 6756 de: +49 89 420 955 854 uk: +44 78 5335 6047 de: +49 17 8545 0880 email and xmpp: [EMAIL PROTECTED]
