Re: [Standards] Markdown in XMPP IM
I'd say go with the XEP-0071 structure with a element and an appropriate namespace (is there a common one? Google turns up nothing). This leaves the standard element to contain your plain text. As to experience, none I'm afraid :) _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: JavaScript ::: XMPP :: + many more ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Github / Twitter / Flickr / Facebook: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI & DDRC - NDAC, Chepstow On 5 January 2016 at 15:49, Peter Waher <peterwa...@hotmail.com> wrote: > Hello > > Does anyone have experience in using markdown in XMPP IM chat applications? > > More and more applications use markdown as a simple way to format text > messages on the fly, and I'm considering using markdown in XMPP IM chat as > well. But instead of sending markdown as simple text in a normal message, I > would like to mark it as such and provide an unformatted text version (with > any markdown formats removed) as well, much like how HTML-IM works. > > Best regards, > Peter Waher > > ___ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > > ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Veto on Privileged Entity
Not XEP-0277 but most pubsub clients should be able to use it at a very basic level. There are many bits that are 'extra' however. I'd like to see Buddycloud being as compatable as possible with 'standard' XMPP with its own sugar. On 17 Dec 2014 23:05, Goffi go...@goffi.org wrote: On 17/12/2014 22:20, Simon Tennant wrote: - 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? Hi Simon, first I made a mistake and Dave is not working on Buddycloud (just using it). I mean by not being standard XMPP that you are developing your own XEPs independently of what's available in published extensions (don't take that as a negative criticism, I have nothing against Buddycloud), that means that we can't receive buddycloud microblogs (or whatever it is called in buddycloud terminology) with XEP-0277 compliant clients. Correct me if I'm wrong Cheers Goffi
Re: [Standards] Whiteboarding with XMPP
How similar is the spec to HTML5 canvas drawing methods? It would be great if we could get something that matched that as closely as possible, meaning browser whiteboarding apps would be very simple to create using XMPP.
Re: [Standards] Cleaning the Wiki
Whilst I agree with you entirely (we could also use Travis to test patches are valid and publish / updated the website) I believe there are some potential legal issues that have come up previously. I *think* the latest gitlab has public repositories but this does not allow for the fork + pull request model we are all used to with github. On 1 Sep 2014 18:37, edhelas edhe...@movim.eu wrote: Yes I was just thinking of Github too. The pull request feature is also really nice for : - Fixing minor issues (typo, english mistake…) - Proposing improvements for the XEP (changes that require major version update). Then we can decide that for such request we talk about it during the meeting. The current process (with the inbox and the validations) can also be changed to a more modern one, linked with the bugtracker/feature system :) On lun., sept. 1, 2014 at 7:25 , Evgeny Khramtsov xramt...@gmail.com wrote: Mon, 1 Sep 2014 19:08:22 +0200 Christian Schudt christian.sch...@gmx.de wrote: Hi, I appreciate the idea to introduce an issue tracker for XEPs (like Jira). It would be way much easier to move XEPs to github and use the corresponding github's bug tracker.
Re: [Standards] Autumn XMPP summit outside NA?
Sorry for the multiple cross posts, but this is relevant to this thread: Hi all, As per previous emails there we now have plans for an XSF summit in Berlin during JSFest. There is an event (for which there aren't much details) called decentralize.js on the 9th of September so we're looking at 2 days from the 10th / 11th / 12th September to hold a 1 day summit and a hackathon/barcamp for the wider community (probably called xmpp.js). We'd like to gauge numbers so we can book the correct amount of space and try and organise a group booking. To that end I've created a doodle below. If you are interested in coming please select your favoured two days and we'll pick those with the most responses: http://doodle.com/t5c6v6eth3vpw82u If anyone would like to help out please let me know (especially if you are from, or know, Berlin). Cheers, Lloyd. ___
Re: [Standards] Autumn XMPP summit outside NA?
There's lots of people saying this would be a good idea, and most (easily accessible) places in Europe are also good for people. Seems it needs someone (maybe a group of 3) to make a decision and run with it. fippo and Lance might be in Berlin mid-September so I'll put my hand up for Berlin again (+ hopefully Mozilla office usage + decentralize.js). We're not going to make everyone happy on location, but a summit, I'm sure, will be better than no summit. _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 25 July 2014 00:39, Stefan Karlsson s...@synergysky.com wrote: Sweden would be nice! ;) Or Norway/Oslo. /Stefan Joachim Lindborg skrev 24/07/14 08:13: Sweden Stockholm would be perfect :) happy to host you all. *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: joachim.lindb...@sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 2014-07-23 17:53 GMT+02:00 Sergey Dobrov bin...@jrudevels.org: Hello folks, We are wondering if anyone would be interested in autumn summit if we'd move it from North America to another place this year? The possible places are welcome to be suggested. Thanks! -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Autumn XMPP summit outside NA?
Another alternative is mid-September around JSConfEU week (13th-14th September) in Berlin, http://jsfest.berlin/ There's an event on the 9th called decentralize.js although I don't have any additional details about it right now. The main conference is sold out but the others still have tickets. We could probably talk to Mozilla about using their space as a venue for the summit too. If its going to be Europe then any easily reachable (for all) European city would be ideal. _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 24 July 2014 07:13, Joachim Lindborg joachim.lindb...@sust.se wrote: Sweden Stockholm would be perfect :) happy to host you all. *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: joachim.lindb...@sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 2014-07-23 17:53 GMT+02:00 Sergey Dobrov bin...@jrudevels.org: Hello folks, We are wondering if anyone would be interested in autumn summit if we'd move it from North America to another place this year? The possible places are welcome to be suggested. Thanks! -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
Re: [Standards] Proposed XMPP Extension: Privileged Components
The bit I was expecting to see, and didn't, was a protocol for trapping and/or intercepting specific namespaces. I think a small amount of expansion of Section 4.2 should do the trick, something like: iq to='u...@example.com' from='u...@example.com/resource' type='set' id='789' privilege handle stanzas='*' namespace='...'/ /privilege /iq This expanded Section 4.2 really needs to be a XEP in itself. I'd see this as a separate XEP myself since we're talking about two essentially different use cases (although I'd assume they'd often be used in parallel). I've read this again and beyond agreeing with many of the other comments, I'm thinking why does this have to be limited to components? Surely an special/admin user to request to act on behalf of another user for some actions?
Re: [Standards] Namespace delegation and privileged component
Yes, this is exactly something I've talked about before (in Portland last year and again at an XMPP UK event) and something Matthew Wild has partly implemented somewhere (the stanza hijacking as I call it). If you are putting something together please include me and I'll try and throw in some ideas. _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 8 May 2014 10:09, Goffi go...@goffi.org wrote: G'day, I bring up this thread as we are currently having an interesting discussion with Binary and Edhelas. Here is the main issue: components are really limited today, they're more something like server side clients, with very limited access (they can access entity roster for example, so a pubsub component can't manage roster access model). We are thinking about two new XEPs to solve this issue: - namespace delegation: a server delegate a full namespace to a component, e.g. a component say I want to manage 'vcard-temp' - privileged component: a component access everything a client can, in the name of the client. That's mean it can access an entity full roster without limitation, it's private storage, etc. That would open XMPP to a huge new step in decentralisation, with these 2 XEPs you could host your own pubsub or PEP component at home. This is also better for security: you may want to host your own gateway because you don't want that the main server access your login/password for the legacy network. An other huge advantage, would be the ability to overpass servers limitations: my server's internal PubSub service doesn't manage roster access ? No problem I had my own PubSub service as a privileged component. That's also mean quick development cycle when you want to try experimental stuff: you don't have to wait for server implementation to test something. Here are the logs of our recents discussions: http://paste.debian.net/98158/ So we'll try to work on protoxep for this now, anybody interested in the subject please manifest yourself :) Cheers Goffi Le mercredi 13 novembre 2013, 18:35:45 Matthew Wild a écrit : On 13 November 2013 18:12, Goffi go...@goffi.org wrote: So, is it possible to remove these restrictions from the XEP ? Or at least to have an unsecure mode, and a secure mode with full access to roster ? This is related to something we discussed at the summit recently - privileged components. I have half an implementation already, which allows components to handle stanzas to the user's bare JID that the server would otherwise handle (or reject). For example it's possible to handle standard vcard queries in a component now. The point I got to was figuring out how the component should reply, since the stanza needs to look like it came from the user. I'll also note here that Prosody at least already supports components faking JIDs (ejabberd does too) when enabled by the admin. Prosody is probably also happy with such components requesting the user's roster, as well as other tasks. However this is definitely *not* in any standard. I'd like to standardise this (in some form), and it seems there are a number of people interested in it too. So we need to solve: - Sending stanzas from the user - Sending stanzas to the user's account, and getting replies Someone put together a protoXEP :) (I already have enough XEP work on my plate for the moment) Regards, Matthew
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
In the latest spec we use a PTR record - but that's not so important. The DNS look up is optional. DISCO response SHOULD always take priority. The DNS look up is for s2s communications and a client is not involved at all. A client always talks to its home buddycloud server. The addition of a DNS lookup is for users like Simon T who use google apps and so their main XMPP server (google) won't allow them to add components. We still use DISCO as its the standard way of performing discovery. DNS is just an additional nice mechanism. _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 28 April 2014 21:53, Edwin Mons j...@edwinm.ik.nu 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
Re: [Standards] Proposed XMPP Extension: Buddycloud Channels
Most recent attached from https://raw.githubusercontent.com/buddycloud/buddycloud-xep/gh-pages/buddycloud.xml Simon, I assume this is correct? _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 28 April 2014 17:52, Matthew A. Miller linuxw...@outer-planes.netwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please send the Editor the canonical XML file as an attachment, and we'll get the inbox proto-XEP updated. - -- - - mm Matthew A. Miller http://goo.gl/LK55L http://goo.gl/LK55L On 4/28/14, 10:45 AM, Steven Lloyd Watkin wrote: Here's the version the script builds - http://buddycloud.github.io/buddycloud-xep/ I think the problem might be between the user and the mail queue :) _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk mailto:ll...@evilprofessor.co.ukll...@evilprofessor.co.uk(email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 28 April 2014 17:39, Ashley Ward ashley.w...@surevine.com mailto:ashley.w...@surevine.com ashley.w...@surevine.com wrote: On 28 Apr 2014, at 17:11, XMPP Extensions Editor edi...@xmpp.org mailto:edi...@xmpp.org edi...@xmpp.org 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. Looks surprisingly short... I think possibly there's something gone wrong with Lloyds build script! — Ash -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTXocwAAoJEOz0ck4QngW7qBYIAKtAHwDcewKi4QkUrwu+r2oI NbHAK2zVeqxm0UHCOpMG+MABiAJQUiCUtRJKOCX/Rz7+d46+MduxVQsAbTBC5eb0 pXW/oNdm3GAUnXu8rIVLp2jpCzlEWL0sIdb/G9RR8WqcBiZScI0e/hfwhd6+qsXu f0TCxjp+YOdBZPSQIRugu80turdx6seN7FD4VVx0okVxg7BEyQtbxXTrvfcb26iM Lg8gcwNp2qheMbiqQdSSxXCEE0Epo9C2ehqcXwMlyrLmfyi1ab/paLQBd7/Jt7rl wN2OIwN5YbdP1XLdbWqkA9ex749HwL6F1iHYbkinTh6dOgZpNm8vuVp+EtAeJ5c= =DInJ -END PGP SIGNATURE- ?xml version='1.0' encoding='UTF-8'? !DOCTYPE xep SYSTEM 'xep.dtd' [ !ENTITY % ents SYSTEM 'xep.ent' %ents; !ENTITY actor lt;actor/gt; !ENTITY invalidactor lt;invalid-actor/gt; !ENTITY invalidnode lt;invalid-node/gt; ] ?xml-stylesheet type='text/xsl' href='xep.xsl'? xep header titleBuddycloud Channels/title abstractThis document describes a profile and conventions for usage of the PubSub protocol in the context of a new type of communication./abstract legal copyrightThis XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF). /copyright permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the quot;Specificationquot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. /permissions warranty ## NOTE WELL: This Specification is provided on an quot;AS ISquot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any
Re: [Standards] Last connection time of friend
If you know the full jid of the device, then you could always ping it? http://xmpp.org/extensions/xep-0199.html _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 3 March 2014 16:47, Peter Waher peter.wa...@clayster.com wrote: Hello Dave Thanks for the quick response. This looks like exactly what I need. I’m a little worried about this statement in RFC 6121 though (and the explanation a little circular): *Presence probes SHOULD NOT be sent by a client*, because in general a client will not need to send them since the task of gathering presence from a user's contacts is managed by the user's server. However, if a user's client generates an outbound presence probe then the user's server SHOULD route the probe (if the contact is at another server) or process the probe (if the contact is at the same server) and MUST NOT use its receipt of the presence probe from a connected client as the sole cause for returning a stanza or stream error to the client. Sending such probes seems to me to be a great way of finding connection problems in Internet of Things networks. Have to do some experiments to find out how it works out. Perhaps the explanation for why this should not be done by clients can be revised in the RFC? Best regards, Peter Waher *From:* Dave Cridland [mailto:d...@cridland.net] *Sent:* den 2 mars 2014 16:21 *To:* XMPP Standards *Subject:* Re: [Standards] Last connection time of friend Some servers also respond to a probe with the last offline presence (with a timestamp). On 2 March 2014 19:17, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 02.03.2014 20:08, schrieb Peter Waher: Is there a means to figure out the last time a friend connected to its XMPP server? Can you ask the server hosting the user account for last connection time? (You might not have been online to receive the presence message when the user went offline.) http://xmpp.org/extensions/xep-0012.html#offline -- not sure how many servers implement it though.
Re: [Standards] Proposed XMPP Extension: COnferences with LIghtweight BRIdging (COLIBRI)
Great work guys. Excited to see the talk from WebRTC Expo (hopefully?) and to start installing and implementing. Lloyd _ Steven Lloyd Watkin Software Engineer PHP ::: Java ::: Ruby ::: Node.js ::: XMPP ll...@evilprofessor.co.uk (email+jid) ::: http://www.evilprofessor.co.uk Facebook / Twitter / Flickr: lloydwatkin Organiser of WORLD RECORD breaking charity event: Scuba Santas ::: http://www.scuba-santas.co.uk Supporting the RNLI DDRC - 15th December 2013 - NDAC, Chepstow On 5 December 2013 10:41, Philipp Hancke fi...@goodadvice.pages.de wrote: On Thu, 5 Dec 2013, Dave Cridland wrote: I read this through. It seems in remarkably good shape for a mere protoXEP, and the protocol looks solid, useful, and well-designed. The protocol is brilliant -- thanks to Emil. I just made it work with the webrtc API. It basically leverages the separation of media description and transport in Jingle to insert the bridge into the media path. I do think it would really benefit from having a diagram - it's not obvious who is talking to what and how, and given the signalling paths differ from the media paths, this doesn't help matters much. Right, I'll see if I can add one showing how to use this with Jingle until next week. Implementing a conference focus is somewhat complicated, but the important point is that the clients participating in the colibri session don't care much, for them it looks like a single session (with multiple videos).
