First, I would like to apologize to everyone who put so much effort into qunu.
Current Status:
The server has been taken offline. There are no backups which are current, the latest is one month old.
Why:
The server that was just taken offline was to be a temporary home lasting one, maybe two months. We were then going to find a more permanent setup. As with most things that have a deadline it received no attention until it was necessary.
Apparently there was some confusion as to the date which the account was to be canceled. It was scheduled to be taken offline on December 21, 2007. However, the server was taken offline nine days before the scheduled time (e.g. today)
A few weeks earlier, Mickaël at process-one had generously offered to take qunu off our hands. So we had finally found the home we had been looking for. I had even started the process of getting all the data off the server. Unfortunately, the transition is not going as smoothly as I had hoped.
Once again, qunu will suffer through a period of downtime before it is finally resurrected again. Maybe qunu should be renamed Phoenix or Lazarus
At some point when all the kinks are worked out, probably next month, qunu will be started at its new home. Don’t hold your breath, but don’t give up hope either.
Justin
I am going to be meeting with Mickaël Rémond at an adhoc ejabberd meeting. afaik, the location is undetermined, however, I am flying out in the morning and have decided that Gramstand is as good of a place as any for now. (primarily thanks to stumbling onto a coworking blog). Will probably move onto a more pub-like venue later on.
I am hoping to meet a few erlang/ejabberd devs on this trip. If not, the chance to chat with Mickaël f2f will definitely be worth the 1.2hr plane ride.
I am taking Jetblue flight1 from Buffalo to JFK and landing around 10:00am. Then finding my way from Queens to Manhattan via the subway. It looks like I will have about 8hrs to play with in nyc.
If you have the time or inclination give me a ring at 585-705-1877 I will be hanging out at gramstand writing erlang.
I just had an interesting chat with hawke about presence and transports. It may seem pedantic, but I think it strikes at an important point. A lot of clients assume that a jid must have a node; miranda,iChat,gtalk come to mind. If that jid lacks a node then it must be a transport, e.g. behave fundamentally different than a typical IM client connection. In other words the jid is being used to determine the basic functionality of an entity on the xmpp network.
Below is the chatlog, but it can be summarized as:
- hawke asserts that presence is a mutual agreement for communication
- I assert that presence is a reflection of an entities availability
This post is a solicitation for opinions.
Below is the chat log
[12:11] hawke> since most clients will show the quser
service as a transport, instead of (or as well as) sending the
message, just send offline presence.
[12:11] hawke> then they can just log back in
[12:11] hawke> instead of the ‘status on’ message
[12:12] zion> thats a bit client specific though
[12:12] hawke> How so?
[12:12] zion> quser is not intended to be a transport
[12:12] zion> just because it doesn’t have a node in the jid
[12:13] hawke> I’ve not seen a client that determines
transport vs. other contact any other way.
[12:14] zion> emacs-jabber ;)
[12:14] zion> yeah… that semantic is annoying
[12:14] zion> so I don’t want to encourage bad habits
[12:14] zion> the client should disco to find out what it is, not use
the jid to assume
[12:14] zion> to many clients to that, and it sucks
[12:15] hawke> True
[12:15] zion> the jid is an identifier, nothing more
[12:15] hawke> But even so, the same thing applies to
quser as actual transports
[12:15] hawke> you still log on and off by sending
presence
[12:15] zion> no… there is not log on/off
[12:15] zion> I added that ability because it was requested
[12:16] zion> its a presence aware node on the jabber network
[12:16] zion> it doesn’t proxy your messages to another network
[12:16] hawke> I think the distinction between
“list/delist” and “logon/logoff” is pretty unimportant for this
purpoose.
[12:16] hawke> too many “o”s.
[12:16] zion> it is important actually
[12:17] hawke> oh?
[12:17] zion> if you go ‘away’ on aim/msn/yahoo then you are still
reachable
[12:17] zion> you are still connected to that network
[12:17] hawke> How does that relate?
[12:17] zion> so there is a diff between list/delist and logon/logoff
[12:18] hawke> Going “away” is different from logging
off though
[12:18] zion> thats my point!
[12:18] hawke> If I send offline presence to a
transport, I am logged off not set away
[12:18] zion> exactly
[12:18] hawke> if I send offline presence to quser, I
am delisted/no longer reachable to the qunu web service
[12:19] zion> there is NO logoff from qunu
[12:19] zion> you will not be listed
[12:19] zion> but quser can still contact you
[12:19] zion> since you are still on the jabber network
[12:19] hawke> Obviously.
[12:19] zion> qunu is a jabber service, not a transport
[12:19] zion> there is a distinct difference and the semantics of a
transport do not apply
[12:20] hawke> I know that; the logic is the same
though — log off/on.
[12:20] zion> if you log off aim, can the aim network still contact
you?
[12:20] zion> no
[12:20] hawke> Only the terminology is different.
[12:20] zion> no its not
[12:20] hawke> but that’s “can’t” vs. “won’t” isn’t it?
[12:21] zion> presence is significantly different than network
connection
[12:21] hawke> if I log off of quser, it
won’t/shouldn’t be inviting me to rooms.
[12:21] zion> inviting is only one activity
[12:21] zion> and there is no ‘log off’ quser
[12:22] hawke> Sure there is
[12:22] zion> *sigh*
[12:22] hawke> if I send offline presence, I am logged
off
[12:22] hawke> am I not?
[12:22] zion> if you send me offline … does that mean I am a
transport?
[12:22] hawke> I am no longer listed in the web
service, and I won’t be invited to rooms any more.
[12:23] zion> just because your client forces those terms in the UI
does not define it
[12:23] hawke> No. I’m not saying it is a transport.
I am saying that the particular action of sending online/offline
presence that applies to transports also applies to quser
[12:24] zion> right. if you send directed offline pres to quser, then
it will think you are offline and treat you accordingly
[12:24] hawke> Yes.
[12:24] hawke> though it will still respond to
messages.
[12:25] zion> I lost track of where we are… we seem to be
disagreeing about something, but saying the same things
[12:26] zion> you want quser to behave like a transport by sending
presence offline instead of using status on/off
[12:26] hawke> Let me restate my suggestion: The status
of quser should reflect the user’s listed status on the quser web
service.
[12:26] hawke> yes
[12:26] zion> my argument is that is not appropriate, because quser is
not a transport
[12:26] hawke> quser is a presence proxy.
[12:27] hawke> (and metadata bot, but that’s not
relevant for this purpose)
[12:27] zion> so quser should send an offline presence to the user
[12:27] zion> which will hide it from the roster ui
[12:27] hawke> I think so, yes. Sending the message,
so that they notice is also valuable.
[12:28] zion> but quser is not offline
[12:28] zion> and the user is not offline
[12:28] hawke> True.
[12:29] hawke> Well
[12:29] zion> imo, pres should indicate the availability of an entity.
[12:29] hawke> the user is “offline” as far as the
website is concerned.
[12:29] zion> not exactly correct. the website is just a jabber
client.
[12:30] zion> so the user is delisted from results, but not offline
[12:30] hawke> and with transports, presence doesn’t
indicate whether the service is available either
[12:30] hawke> it indicates whether or not you’re
logged in to it.
[12:30] hawke> For the purposes of the website, what’s
the difference between being delisted and offline?
[12:30] zion> currently, nothing ;)
[12:31] hawke> QED.
[12:31] zion> qed?
[12:31] hawke> http://en.wikipedia.org/wiki/Q.E.D.
[12:32] zion> ex: we are going to be incorporating pubsub into the
service
[12:32] hawke> OK..
[12:33] hawke> Does the users presence have any effect
on pubsub?
[12:33] zion> it should
[12:33] zion> e.g. if they are really ‘offlien’ vs ‘away’
[12:34] zion> if pres != chat || online then they are delisted
[12:34] hawke> OK..
[12:34] zion> if pres != chat || online || dnd || away || xa then send
them pubsub events
[12:35] hawke> So, only send them pubsub events when
they’re offline, or am I missing a status there?
[12:36] zion> only send them pubsub events when they are connected to
jabber, if they are offline don’t
[12:36] zion> there is a diff between ‘I am connected’ and ‘I am
online/away/xa/etc..’
[12:37] hawke> but surely you can send pubsub events
regardless of quser’s status?
[12:38] zion> of course… we could set it to offline and still send
stuff
[12:39] hawke> As I see it, the user sending directed
offline presence [to quser] means “I don’t want you to talk to me any
more”; quser then sends its own offline presence confirming that.
[12:40] hawke> So when quser decides “I’m not going to
talk to you any more” it should do the same thing.
[12:41] zion> you assertion is that presence is a mutual agreement of
communication
[12:41] zion> my assertion is that presence is a reflection of an
entities availability
[12:41] zion> regardless of its role
[12:42] hawke> OK, so amend that to add “…unless you
talk to me first.”
No plan survives contact with the enemy. This was made abundantly clear when Qunu was released as alpha for the public to abuse. As with any alpha there were countless problems that I dealt with on a daily basis. Clients insisting that a jid must have a node, xdata limitations in iq:register, double subscriptions, broken muc support, etc…
For some of these problems I was able to hack up a work around, such as quser@qunu.com as a subscription proxy for quser.alpha.qunu.com. A few of them had no decent solution and I had to suggest other clients. The wiki page, http://qunu.com/wiki/index.php/Documentation, has a list of clients which have the bare minimum feature set.
The default gtalk client does not support muc or groupchat. Since a lot of people had a gmail account they naturally tried to use their gtalk clients. Making the brash assumption that gtalk behaved like every other xmpp server I directed them to the above list of working clients to try. After several confusing chats and some poking of my own I quickly discovered that gtalk is not xmpp.
That may sound rather harsh so let me qualify that. While google’s xmpp-like servers may follow the letter of the xmpp RFC‘s they most certainly do not follow the spirit. The reason I say this is that the gtalk servers will block any stanza which their default client will not understand regardless of which client you are actually using. This means that even if you wanted to get cool new features by using another jabber client, gtalk will block the stanzas before they get to your client. Not only do you have to get a different client, but you have to use a different server. *sigh*
The biggest issue, at least for qunu, is muc invites. GTalk silently drops them regardless of which client is on the other end. disco requests are reported assuming the default client. iq:version is always reported as not implemented, again ignoring the client.
Of course there is no bug/issue report system at google. Thus this blog post. Hopefully someone at gtalk will see this and file a bug. Of course, if you need further clarification, feel free test this yourself or ping me at zion@openaether.org
After many long nights and lots of bug squashing we are finally ready to open up Qunu for general abuse. This is an invitation for everyone in the jabber community to try it out. Let us know what you think and how Qunu can be made better.
So what is Qunu?
<marketing-speak>
In a nutshell, Qunu is a Jabber-based ‘ask-an-expert’-style service that you can ‘tag’ yourself with. Qunu allows you to use your existing jabber client instead of forcing you to lurk on a web forum, irc channel or muc room. In essence, people looking for help come straight to you, the expert.
</marketing-speak>
How it works
Someone on our site searches for help in an area in which you have tagged yourself. They can request an anonymous chat with you. We then send a MUC invite to your jabber client which you can accept or reject. We only send thru invitations when you’re online and available, and you can change your presence with us at any time. You have total control.
<marketing-speak>
It’s a great way to give your expertise back to the community in a non-annoying,
non-intrusive way. You can give help when it’s convenient for you, and best of all, you get to see the ‘thank you’.
</marketing-speak>
How to get in
In order to accommodate the various ‘quirks‘ of all the jabber capable clients out there we have setup lots of ways to get in.
The end result of all this is to get quser.alpha.qunu.com on your roster.
Let us know
This is an alpha release. We would love your feedback.
General discussion is in alpha@muc.alpha.qunu.com. The wiki at http://qunu.com/wiki and of course using qunu via http://alpha.qunu.com/search/qunu
here is the second version of the patch.
Fixes:
- The decline code now checks to see if it is indeed a muc packet via a namespace check.
- It also verifies that the decline is sent to someone, i.e. there is a to attribute value on the decline element
- It now determines the real jid of the declinee. Since the inviter’s nick will be used in nonpublic rooms. If the decline@to is not a jid, then it tries to convert the decline@to from a nick to a jid.
- I moved the hash remove code into the decline function. Since the invitee should only be removed on a successful decline.
I would appreciate it if someone could look at the code and let me know if everything is being freed properly. I am still not sure about the room->member hash table content. It is a duplicated xmlnode. However, if I try to free it a segfault occurrs.
ping me for any feedback, xmpp:zion@openaether.org
http://blogs.openaether.org/data/muc-decline-2.patch
I just hacked this up. It works, kind of
The patch is against 0.6 and not the latest cvs.
Basically, the problem is that when an invitation is declined, it is sent to the room. but the sender is not in the room, so they get an error back. Of course this is incorrect behavior.
Since the jid is added to room->member and not room->remote, mu-conf thinks it is getting a message from the outside. What this does is check to see if the sending jid is a member and try to process it as a decline.
I need to hack some error checking into it before its releasable. Figured I would get some feedback first.
Things I am not sure about:
- does the item in the room->member hash need to be freed? I tried and it causes a segfault.
- is everything that needs to be freed done right in the new func?
http://blogs.openaether.org/data/muc-decline.patch
For various arcane reasons I was inspired recently to browse the TOS (terms of service) for the big closed garden IM networks, AIM, MSN and YahooIM. Some parts are very interesting, some are simple legalese.
- Can I use 3rd party clients like Gaim, Miranda, etc for these networks?
No
You can only use the software provided by the respective service to access their network.
AIM
Restrictions on Access to or Use of AIM Products
You may access AIM Products only through the interfaces and protocols provided or authorized by AOL. You agree that you will not access AIM Products through unauthorized means, such as unlicensed software clients, and that you will only use AIM Products in conjunction with AOL authorized products and components.
YahooIM
Section 11
You agree not to reproduce, duplicate, copy, sell, trade, resell or exploit for any commercial purposes, any portion of the Service (including your Yahoo! ID), use of the Service, or access to the Service.
and
Section 17 (end of second paragraph)
You agree not to access the Service by any means other than through the interface that is provided by Yahoo! for use in accessing the Service.
MSN Messenger
Seciont 3 (last paragraph)
You may only use Microsoft software or authorized third-party software to sign into and use the Service. You can find a list of authorized third-party software at http://messenger.msn.com/Help/Authorized.aspx.
Interestingly, you can only use MSN to discuss personal affairs. The moment you discuss work related topics you violate the TOS. See section 3 first paragraph
We provide the Service for your personal use. You may use the Service while you are at work, but you may not use the Service to conduct business without a separate written contract with Microsoft.
Anyone else out there found interesting restrictions on the closed garden networks? Interesting being defined as non-intuitive.
cvs -d:pserver:anonymous:@cvs.jabberstudio.org:/home/cvs co jeps
cd jeps
wget http://blogs.openaether.org/data/depgraph.xsl
wget http://blogs.openaether.org/data/single.xsl
wget http://blogs.openaether.org/data/depsingle.sh
sh ./depgsingle.sh XXXX
Where XXXX is a full jep number, 0045 is a nice one to test with.
The colors mean:
- Active/Draft/Final = green
- Experimental/Proposed/ProtoJEP = blue
- Deferred/Depredated/Retracted = red
- unkown = black
NOTE: jep 0068 points to 004 as a dep. It should be 0004 (notice 3 zeros) if you want a correct graph edit the dep list in 0068.
EDIT: Jep 0119 is a good example to use, have a look at http://blogs.openaether.org/data/0119.png
I hacked up a quick dependency graph of all the JEPs thanks to this post from Nolan
Its a combo of some simple xsl and bash, and quite simple to run yourself.
cvs -d:pserver:anonymous:@cvs.jabberstudio.org:/home/cvs co jeps
cd jeps
wget http://blogs.openaether.org/data/depgraph.xsl
wget http://blogs.openaether.org/data/depgraph.sh
sh ./depgraph.sh
You will need libxml2, libxslt and graphviz
If you want, you can view a png. Though its quite pointless.
It has everything in it, include obsolete and deprecated jeps. Might get around to filtering those and post another image.
The jabberd project team is pleased to announce the release of jabberd 2.0s10. This is a stable release. This release has no major outstanding issues and is considered usable in production.
Downloads are available here:
http://jabberstudio.org/projects/jabberd2/releases/
md5sum: e8df4a9a5680009071204d423cff2de0
Direct: http://files.jabberstudio.org/jabberd2/jabberd-2.0s10.tar.gz
Bug reports and feature requests should be submitted using the tools on http://j2.openaether.org/. General support requests should go to jadmin@jabber.org. Anything else should be sent to jabberd@jabberstudio.org
ChangeLog:
- fixed SASL anonymous, bug#126
- fixed edge cases with new dynamic jid code
- fixed incorrect free order in c2s, bug#125
- corrected debug logging, bug#119
- fixed s2s bus error on 64-bit architectures, bug#122
- fixed c2s collisions due to long jids, bug#118
- fixed error response to iq result, bug#110
- fixed roster pushing packets without id, bug#73
- applied new dynamic jid patch, bug#100
- fixed double free of nad in c2s and s2s, bug#97
- major memory enhancement, made jid structure dynamically allocated, bug#100
- fixed glibc error with custom sql statements, bug#106
- fixed segfault with keepalives, bug#102
Thanks to:
Michal Kara
Jeremy Lunn
kolargol
David Alexander
Jack Moffitt
Christof Meerwal
Magnus Henoch
David Sansot
Stephen Marquard
I opened a bug at wikimedia to try and get default xmpp uri support. Its been closed as won’t fix and reopened. If you have anything to add to the conversation (preferably in support of it being added), please do so.
The patch I submitted is up and running at wiki.jabber.org and works fine.
… or at least nothing new for those of us that have been drinking the jabber kool aid for years now. Johannes points out some areas that are under exploited by xmpp.
- pubsub
- pubsub-rss
- rest/soap
- urls
Of course, most of what he lists is already defined as jeps, and there are a few impl’s out there…. wait… then whats the problem?
dictbot is dead!
long live dictbot2!
The dictionary bot I had setup on xmpp:dict@openaether.org became so popular it blew up. It accumulated 2,330 roster entries, it was constantly running out of karma. I killed it and started xmpp:dict2@openaether.org. Lets see how long it takes for ppl to kill this one
EDIT: warning!! links are not work safe
quick!
search on google for "jabbercentral.org", or just click It is most entertaining.
At least we can now answer the question, "How will jabber get it's users laid?"
Just rolled out jabberd2 s8. For your convenience here a shortened version of the announcement:
Downloads are available here:
http://jabberstudio.org/projects/jabberd2/releases/
md5sum: 96753c5e74676ace0841a4cee9f13fdb jabberd-2.0s8.tar.gz
ChangeLog:
* fixed s2s segfault from resolver race condition bug#59
* fixed mem leak in s2s bug#59
* added oracle support.
* add keepalives to router bug#54
* fixed info in PROTOCOL file
* Fixed handling of (un)subscribe packets for XMPP-IM compliance
* fixed time values which were not stored correctly
* the ‘>’ must always be escaped (andrey)
* fixed failed access_check() in hpux-ia64
* fixed ssl memory leak
* fixed s2s segfaults relating firewall problems
Thanks to:
Stephen Marquard
Nick Kolargol
Nathan Christiansen
Gonzalo Barrio
Jeremy from jabber.org.au
Andrey
Jack Moffitt
yonghany
The debian distro is well known for being rather strict on what it accepts into its distribution. This has caused Jamin Collins to examine the licensing of jabberd 1.4.x. Turns out its quite a mess. The thread on jdev makes a good read.
Thanks to all the patches and contributions from the jabber community, jabberd2 has seen another release. Which means bug#14 is closed.
With that we open bug#41 for all the new incoming patches
As always, if you have ideas or a simple wishlist for jabberd2, add them to the wiki
The w3c announced the relaunch of URI Activity. Does this mean the now closed xmpp-wg should talk to them about xmpp-uri?
I would like to thank Chris Mullins for asking some questions about Pubsub. Some of which I have wondered about myself.
