Re: [jdev] RFC: Pontarius 0.1 Features Draft
Hi, On 16.11.2010 17:35, Jon Kristensen wrote: > On 11/16/2010 08:32 AM, Dirk Meyer wrote: >> An XMPP-based media server was part of my PhD thesis. If you have a >> lot of free time: http://elib.suub.uni-bremen.de/diss/docs/00011878.pdf >> If you don't, take a look at chapters 2.1, 6 and 7. They contain the >> use cases for my idea, the generic secure architecture and what you >> can do with it. > > Wonderful! I will start reading today! :) That will keep you busy :) > Have you coded anything in regards to this so far? The basic architecture is done including secure Jingle streams based in TLS and IBB. The proof of concept for the Jingle SOCKS5 streams was done by someone else. You can find most of my code in the Freevo SVN in svn://svn.freevo.org/kaa/xmpp (you also need kaa.base which is located in /kaa/base) > Right now we're actually considering revising the features for 0.1 to > only support only "managed media", the higher level system of file(s) > and metadata. I'm just thinking about the scope of the project and that > there are better tools for remote file systems. An arbitrary file could > of course be uploaded using something like a "Object" managed resource, > but that's not what the typical use case would be like. What do you > think about this? One might think there are remote file systems, but in fact it is not so easy. How do you access a file stored on your home server behind a NAT? How do you make this secure? And how do you prevent someone else you want to give access to one file from accessing all? That is considered in my thesis but not implemented in a ready-to-use way. Regards, Dirk-- An aquarium is just interactive television for cats. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] RFC: Pontarius 0.1 Features Draft
Hi Jon / Hi everyone else, even though you also sent me a personal mail, I guess it is a better idea to answer to the list. Maybe someone else wants to join in. I'm not dead, only very busy with a job completely unrelated to XMPP. :( On 13.11.2010 00:30, Jon Kristensen wrote: My name is Jon Kristensen and I am planning to create a XMPP-based media server called Pontarius. The typical use case of Pontarius (0.1) would be to host all your media on a local server and have that server share it with your friends (with customizable permissions). In the future it will also be a foundation for services of different kinds. We will be making heavy use of the XMPP protocol. An XMPP-based media server was part of my PhD thesis. If you have a lot of free time: http://elib.suub.uni-bremen.de/diss/docs/00011878.pdf If you don't, take a look at chapters 2.1, 6 and 7. They contain the use cases for my idea, the generic secure architecture and what you can do with it. I just wanted to let you know that we have produced a draft of the features for the first version of Pontarius. You can read it http://www.pontarius.org/pontarius-0-1-features-draft/. Also see the comments. We would appreciate any feedback! :) Sounds good. A gvfs backend would be cool to get an easy integration. Besides not having time to work on XMPP I'm the maintainer of Freevo (http://www.freevo.org) -- also no time lately, but if I do, I want to integrate the ideas into Freevo. Right now, the lack of free time is the main reason why I don't continue the work. But I still plan to do so. If we can join forces (and maybe other people) this could help a lot. I don't have time to write XEPs or hack code, but I do have some minutes for discussions. Regards, Dirk ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] XMPP Developer Position at SocialVision, Inc.
"Karthik Kailash" wrote: > Our company is looking for a talented developer to help us build our > service on top of XMPP. I asked around and was advised to post to > this list. Details on the position are below. Not that I'm interessted, but it may help if you add a country information somewhere. Dirk -- A tree never hits an automobile except in self-defence. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Fosdem 2010
Peter Saint-Andre wrote: >> 2. Specify the username in the SRP handshake to be the initiators fullJID > > Why the full JID instead of the bare JID? Because the session is being > set up between a full JID pair? No reason. We could agree on a fixed string 'foo' if you like. :) Bare JID, full JID, only the user name, or fixed string 'XTLS' does not matter in our case. Any preferences? Dirk -- "Good judgement comes from experience. Experience comes from bad judgement." -- Evan Hardin. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Fosdem 2010
Peter Saint-Andre wrote: >> Has the e2e encryption / XTLS work advanced enough to do an e2e security >> sprint around Fosdem? > > I think so. I have a reference implementation. XEP-0189 key management needs some more love by the pubsub versioning discussed on the pubsub list. BTW, I plan to update the XTLS draft soon with two changes: 1. Make SRP optional if we prefer the leap of faith 2. Specify the username in the SRP handshake to be the initiators fullJID Dirk -- Microsoft spel chekar vor sail, worgs grate !! ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] xmppony 0.1 is released!
Anaël Verrier wrote: > I don't understand why people do not like threads :'( Because you get race conditions >From one of your other mails: > Gajim uses non-blocking sockets to not have to use threads. I do not > think only it is necessary to neglect the use of threads just to not > have to be bored with, especially at the hour of the processors > multi-cores. Python does not benefit from multi-cores when using threads. The interpreter lock makes multi-core useless unless you are in a C module and release the lock. Gajim will not benefit from threads at all. Dirk -- Those that make the rules don't play the game! ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] a vision
Dave Cridland wrote:
> On Wed Mar 11 18:16:32 2009, Remko Tronçon wrote:
>> As a goal, this doesn't say much to the average user indeed.
>> However, you could swing it in a way that says "Connects/Works
>> with/... popular services such as Google Talk, Live Journal, ..."
>> Security could indeed also appeal to some (I think people like to
>> hear that what they're doing is 'secure', they don't even need to
>> understand). Accountability and transparency, that I don't really
>> know why that would be useful.
>>
>>
> Oh. I didn't think this was about useful. I thought this was about
> convincing Dirk's sister with impressive sounding buzzwords that we
> can backup with some kind of fact.
Right. It is all about marketing. It would help (not for my sister) if
we easy MSN/AIM/ICQ integration (gateway) in the servers and an EASY way
to provide the credentials. That makes switching painless for everything
except Skype ("You can still talk to your friends").
Take a look at the Skype website: it is presented in German for me (I
giess based on the IP address), a big photo (makes no sense, but it
looks like web 2.0), and a button "download". I guess that is what we
need. The download would be a problem:
1. Do not let the user choose between x clients. Jabber.org should have
one default client for Windows/MAC users (Linux users are grown up,
they already know how to choose stuff).
2. The client must have Jingle support incl. Video
3. Userfriendly setup. E.g. a wizzard asking me if I already have an
account or if one should be created. It has to include a list of XMPP
servers for the user to choose. The list should be short.
4. The client must be able to auto-update itself. Users do not check for
new versions, the software has to do that.
World domination is a slow process. :)
Dirk
--
My mind not only wanders, sometimes it leaves completely.
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___
Re: [jdev] a vision
Peter Saint-Andre wrote: > For me the idea here is that jabber.org will be the community-driven > "running code" laboratory for the formal "rough consensus" technologies > produced by the XMPP Standards Foundation. The goal is to build an open > and distributed IM, presence, data, and VoIP service that can provide a > realistic alternative to closed systems like Skype. We should be prepared to answer the question why Jabber? My sister has a Skype account and her friends also have one. Why should she download this Jabber thing? Don't answer with freedom and open -- that has no meaning for the average user. Dirk -- Microsoft Windows didn't get as bad as it is overnight -- it took over ten years of careful development ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Monthly XMPP Meeting
Peter Saint-Andre wrote: > I just started looking at Sphinx, which is used to produce documentation > for Python and lots of other projects: > > http://sphinx.pocoo.org/ > > It looks intriguing to me. We started using it for Freevo some weeks ago and we like it. It is a very good documentation system. Of couse, we also like that it has some autodoc feature for Python code the XSF does not need. Dirk -- A 14.4 modem makes you want to get out and push! ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Monthly XMPP Meeting
Peter Saint-Andre wrote: > One solution here is to build out a developer-oriented documentation > site. As we discussed in Brussels, Python developers don't read the > PEPs, they read the docs. Right > We have only XEPs because it's a lot of work to write > developer-friendly docs, but we have a start here: > > http://xmpp.org/tech/ > > Let's build that out further at that site or on wiki.xmpp.org. I don't want to start a discussion now, but a wiki may be better since everyone can add stuff. And I missed something I hate about XMPP: the name. You can google something, you can send a mail, browse the web, you can even skype someone. But I can't XMPP -- it is not word. Dirk -- Quitters never win, and winners never quit, but those who never quit AND never win are idiots. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Monthly XMPP Meeting
Peter Saint-Andre wrote: > On 3/9/09 2:43 PM, Peter Saint-Andre wrote: >> I think it would be valuable to hold a groupchat once a month as a venue >> for community discussion. I'm calling this the "Monthly XMPP Meeting" or >> MXM (you can pronounce it like "mix 'em"). I propose that we hold the >> first discussion this Thursday, March 12, at 20:00 UTC in the chatroom >> at j...@conference.jabber.org. If there are topics you'd like me to put >> on the agenda, please let me know. Otherwise I'll just make it up. :) > > OK, I came up with a theme for this meeting: "Why I Hate XMPP". :) > > https://stpeter.im/?p=2528 Good starting point. I like the first one and have more details to it: If I want to create a client/server, what do I need to implement? Yes, there are XEP-0242 and XEP-0243, but I'm scared of before I scrolled down to that point What do I need to implement VoIP would be answer question. But back to the question about what I hate: 1. Specs are not always written for developers. It looks code on paper but it does not fit into the state machine of lib/client foo 2. Many experimental XEPs are not implemented because nobody wants to be the first. Or "I can not implement it in a client without server support" and "It makes no sense to implement it into a server without a client using it" 3. Some XEPs have a scary small scrollbar in my browser. I don't want to read everything (good example is PubSub) Dirk -- I am a friend of the working man, and I would rather be his friend than be one. -- Clarence Darrow ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Scope of current RFC3920 SASL implementation
Justin Karneges wrote: > On Sunday 25 January 2009 10:30:39 Dirk Meyer wrote: >> If you only do SASL, you can not be sure that someone changes the data >> after the SASL authentication. Maybe you don't need to if you trust the >> XMPP servers involved. > > It depends on the SASL mechanism. With DIGEST-MD5, for example, you can have > a mutually authenticated session with integrity protection (and encryption). I did not know that. > I think our e2e proposal should promote TLS + SASL EXTERNAL as the common > case, but we should not require TLS and we should allow any SASL mechanism. > This way, someone could create a password-based service running at a JID. It may get things more complicated, but agree, it should be considered. This seems to be the logical choise for communicating with external (web) services. Dirk -- The three most dangerous things are a programmer with a soldering iron, a manager who codes, and a user who gets ideas. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Scope of current RFC3920 SASL implementation
Richard Smith wrote:
> Dirk Meyer wrote:
>> Thinking of web services connected over XMPP, this sounds useful. Maybe
>> we can define some sort of SASL in IQ stanzas. But this will be an
>> insecure connection. Maybe you want to use E2E security in this use
>> case.
>
> E2E secures the transport... SASL in IQ stanzas would authenticate the
> user... This is my thinking at least...
Yes, but if we need authentication to make the transport secure, we need
to know that there is no man-in-the-middle. I guess TLS-SRP would work
perfect for you: the user provides a password with SRP and the peer
provides a certificate the user can check. Based on that the channel
will be secure.
If you only do SASL, you can not be sure that someone changes the data
after the SASL authentication. Maybe you don't need to if you trust the
XMPP servers involved.
Dirk
--
panic("kmem_cache_init(): Offsets are wrong - I've been messed with!");
2.2.16 /usr/src/linux/mm/slab.c
___
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
___
Re: [jdev] Scope of current RFC3920 SASL implementation
Richard Smith wrote: > I've read through the SASL sections, and it doesn't actually say that > the authentication scheme cannot be used in-band to communicate with a > remote host? > > So, I know it's probably unsupported by most if not all the clients, but > is it possible to re-use SASL namespaces to authenticate a user against > a remote XMPP component using SASL? Thinking of web services connected over XMPP, this sounds useful. Maybe we can define some sort of SASL in IQ stanzas. But this will be an insecure connection. Maybe you want to use E2E security in this use case. Dirk -- This is Linux country. If you listen carefully, you can hear Windows reboot... ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] XMPP Summit
Jonathan Schleifer wrote: > Am 10.12.2008 um 20:11 schrieb Dirk Meyer: > >> Great. A question to day 2: I guess the priority will be on "XMPP as >> Skype replacement", so RTP over Jingle, ICE-UDP and friends. But we >> should also have a discussion about the future of Jingle for TCP-like >> requirements like file-transfer and e2e streams (see day 3). So ICE- >> TCP >> or something like this comes to my mind. I never was on an XMPP summit >> before, but maybe split the Jingle discussion into three parts: Jingle >> basics, UDP (VoIP), and TCP (ICE-TCP, TURN, etc). > > Well, actually, UDP for file transfers can be desirable if you want to > circumvent NAT. :) So UDP can work where TCP doesn't. Of course, you > then need integrity checks. I know. But maybe one client is not behind a NAT. In that case we could open a TCP connection directly. Or one client behind a NAT has UPnP IGD or NAT-PMP support in the router. It would be a shame to go into the UDP trouble if one of these solutions work. >> And one note to file transfer on day 3: are there any ideas to support >> seeking in file transfers? It would be a nice feature and I already >> have >> some ideas. Maybe we can discuss it, too. > > Streaming audio/video where you can seek? :) Yes. > Maybe this should be implemented in Jingle Audio/Video and not in > Jingle File Transfers. I don't like RTP for my use case. Why sacrifice a packet that is too late when you are watching a video from your home server? I don't need the real-time from RTP in this case. I will go into details in a post on the standards list. Give me some time to sort my memory. :) > But OTOH, seeking in File Transfers would allow > something like XMPPFS :). And it shouldn't be too hard to code for Linux using Fuse. I wrote a small Fuse filesystem once, not a big deal. It sounds like a very crazy idea ... I like it. :) If there is djmount [1], why not XMPPFS? Dirk [1] http://djmount.sourceforge.net/ -- Life's unfair - but root password helps! ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] XMPP Summit
Peter Saint-Andre wrote: > Dirk Meyer wrote: >> Peter Saint-Andre wrote: >>> http://xmpp.org/summit/summit6.shtml >> >> Great. A question to day 2: I guess the priority will be on "XMPP as >> Skype replacement", so RTP over Jingle, ICE-UDP and friends. But we >> should also have a discussion about the future of Jingle for TCP-like >> requirements like file-transfer and e2e streams (see day 3). So ICE-TCP >> or something like this comes to my mind. I never was on an XMPP summit >> before, but maybe split the Jingle discussion into three parts: Jingle >> basics, UDP (VoIP), and TCP (ICE-TCP, TURN, etc). > > Yes, I think the focus for the hackfest will be on voice and video chat, > which is being added to a lot of codebases right now. Topics for > discussion while people are hacking might include the things you > mention, plus multi-party voice and video (a.k.a. Mingle). Great. I would like to have a small group of people not busy hacking and doing inter-op tests to discuss a future ICE-TCP-like XEP. There are so many questions and ways to do it, I would prefer a live-discussion before writing down a XEP proposal. >> And one note to file transfer on day 3: are there any ideas to support >> seeking in file transfers? It would be a nice feature and I already have >> some ideas. Maybe we can discuss it, too. > > Yes, please. :) Ok, I will write a use-case and some basic ideas to the standards list soon. Dirk -- Maryann's Law: You can always find what you're not looking for. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] XMPP Summit
Peter Saint-Andre wrote: > http://xmpp.org/summit/summit6.shtml Great. A question to day 2: I guess the priority will be on "XMPP as Skype replacement", so RTP over Jingle, ICE-UDP and friends. But we should also have a discussion about the future of Jingle for TCP-like requirements like file-transfer and e2e streams (see day 3). So ICE-TCP or something like this comes to my mind. I never was on an XMPP summit before, but maybe split the Jingle discussion into three parts: Jingle basics, UDP (VoIP), and TCP (ICE-TCP, TURN, etc). And one note to file transfer on day 3: are there any ideas to support seeking in file transfers? It would be a nice feature and I already have some ideas. Maybe we can discuss it, too. Dirk -- My Other car is a beater (On the back of a beater). ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
[jdev] First public release of the kaa.xmpp library
Hi, it took me a long time, but I guess it is time to move my XMPP library to a public SVN. The library is written in Python for the kaa framework (outdated info at http://www.freevo.org/kaa). Licence is LGPL. Some notes: 1. The library is designed for bot-to-bot communication and not for users chatting. It does not even supports s and stuff like that. If you want to use the lib for that, you need to send a patch. 2. The main reason for publishing my current (work in progress) code is that it supports most of the stuff you need for end-to-end security: - XEP-0174: Link-local Support - XEP-0247: Jingle XML Streams - XEP-0246: End-to-End XML Streams - XEP-0250: C2C Authentication Using TLS (no OpenGPG) Support for XEP-0189: Public Key Publishing is planed. I have no server that supports everything XEP-0189 requires. 3. The library is only tested against an ejabberd and itself. The error handling is kind of poor -- if something is wrong you will see it on stdout / a logfile. 4. There is a test case in svn to test e2e security. You need to provide username, servername, and password in the test file. Sources: svn://svn.freevo.org/kaa/trunk/xmpp You need kaa.base from svn and have it installed before trying to install kaa.xmpp. svn://svn.freevo.org/kaa/trunk/base For questions about kaa.xmpp or kaa in general, contact me directly, use the freevo devel mailing list, or ask at #freevo on irc.gnu.org. Have fun, Dirk -- Those that make the rules don't play the game! ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] FOSDEM 2009, any xmpp?
Ralph Meijer wrote: > Last year there were as many rooms as the years before, but the > selection wasn't on first come, first serve anymore. With twice as many > applying projects as there are rooms, we didn't make it this year. I > hope that with the hightened attention to XMPP we will get a room this > year. Stupid question from someone who only knows "normal" conferences: What happens in the XMPP room? I read about inter-opts and discussions. How does this work? There are so many interessting things going on, are there also some small presentations and demos? I would love to see Jabber going Social in action and my playing using XMPP as UPnP++ may also be interessting for some people. > Besides that, the FOSDEM team welcomes suggestions for speakers for the > general tracks via a form on the site. We might want to propose a > speaker, too. Maybe the speaker should point out what is going on here: Jabber going Social and the FSF seeking for a Skype replacement are good starting points. Dirk -- Don't trust reality. After all, it's only a collective hunch. ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
Re: [jdev] parsing xml (xmpp) with ruby
Eric Will wrote: > There is no simple way to reason out when a stanza has ended. The > way everyone seems to use is "use a SAX parser, then make a DOM out > of that" which, to me, sucks. You do not need a real DOM with parent and stuff like that. I parse the stanza from a SAX parser into a simple Python object for the stanza. > Plus, I'm using Ruby, so if I'm using a C parser like libxml to do > the SAX, and then do all this mumbo jumbo in Ruby, it's going to > cost me in terms of performance pretty badly. The parsing is the hard part, creating some simple objects in Ruby should be easy. > My question is this: how often could this happen, TODAY? Well, maybe not today. I guess most clients create the stanza and send it in one send() call. But if your code crashes somewhere on a bad stanza, it is a perfect DOS on your server. But one read() could give you more than one stanza. How do you plan to detect this? > I think that's the client's problem. The client works as expected, if your server can not handle this, your server is broken. > How bad could it be if I chose to simply ignore this and see what > happens? I'm one of 'everyone' your wrote about earlier: use SAX. Dirk -- "We're back to the times when men were men and wrote their own device drivers" -- Linus Torvalds ___ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] ___
