On 19 January 2014 21:28, Daniel Pocock <dan...@pocock.com.au> wrote: > On 19/01/14 10:46, Dave Cridland wrote: > > On Sun, Jan 19, 2014 at 8:43 AM, Daniel Pocock <dan...@pocock.com.au> wrote: >> >> As mentioned in the other email, FOSDEM is coming up, maybe that will be >> an opportunity to discuss in person? (Please don't let my .au domain >> deceive you, I'm based in central Europe) > > >> Sadly, I don't think Matt is joining us this time around; perhaps this might >> change his mind, though. There'll certainly be other Prosody developers >> present, though, I'd hope.
I wasn't, but I'll see what I can do. > Just some initial discussion points for the Debian implementation, if > anybody could comment on any of these areas we could start building up a > wiki about it and that will evolve into the project plan: > > a) the DSA team always prefer to use packages from the stable distribution > (or the stable backports), is there any compelling reason we should not use > those versions for this project? Here they are: > http://packages.qa.debian.org/p/prosody.html > - stable= 0.8.2 > - backports = 0.9.1 > I see 0.9.2 is on the Prosody web site - to get that into backports probably > takes at least three weeks anyway I strongly recommend 0.9.x if you can - we put in a lot of work improving lots of things, in areas such as performance and security enhancements. > b) Debian Developers have been given RTC passwords for TURN and SIP and > hopefully XMPP. They are hashed using HA1 for DIGEST/HMAC algorithms such > as SIP and TURN. Can XMPP use these password hashes or do we need to hash > them in some other format? Sure, Prosody has pluggable authentication, whatever format you have should be pretty easy to use. > c) the user passwords are available in two ways: we can supply a text file > directly to the server (see the format used by reTurn, link below) or via a > FreeRADIUS server with the rlm_digest module - can Prosody use either of > these solutions or do we need to come up with something else? We don't have a RADIUS plugin yet, but it's on my todo. > reTurn users.txt sample (we use HA1 in the third column now): > https://github.com/resiprocate/resiprocate/blob/master/reTurn/users.txt That seems trivial, is the SHA1 just a plain SHA1 of the password? or is it salted or what? > d) IPv6 - any new stuff we do in Debian has to be dual stack, should this be > fine with Prosody? Ah, this is a little tricky if restricted to only with stable/backports. Prosody 0.9.x supports IPv6, however it requires a newer version of lua-socket to support it. Upstream are going slow with releasing, but they have issued a release candidate which is packaged and available in unstable and testing. I don't think it would be hard to backport. > e) other dependencies, e.g. databases. Debian infrastructure currently uses > PostgreSQL (no MySQL) but if possible, using no database at all, keeping > each process somewhat self-contained. Looking at the package dependencies, > I see that several databases are suggested. Could anybody comment on just > how compelling it is to use a full SQL database, can we happily use the > sqlite3 driver, etc? Prosody uses the filesystem by default, and this works fine for all but the largest installations. If you need SQL then yes, we support Postgres or SQLite, but I don't think you gain anything except perhaps interop with other applications (but there are other ways to achieve that too). > f) collaboration with the SIP infrastructure: is there any practical way to > share presence services, chat messages or anything else just yet? We don't > have any presence server for SIP right now, it would be nice to plan the > strategy for that alongside the XMPP planning Probably a little more work, but something I'd love to investigate further. I know there are various SIP<->XMPP things around, including some based on Prosody, but I'm not really in the SIP world enough to know the full state of things. Regards, Matthew
