waves in the aether

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

Just ran into this emacs key binding. Someday I need to just read the manual and mark all the stuff I wish I knew already for later study. But since I will probably never do that here is yet another cool thing in emacs which I didn’t know about:

C-x h runs the command mark-whole-buffer
which is an interactive compiled Lisp function in `simple.el’.
It is bound to C-x h,

.
(mark-whole-buffer)

Put point at beginning and mark at end of buffer.
You probably should not use this function in Lisp programs;
it is usually a mistake for a Lisp function to use any subroutine
that uses or sets the mark.

If you didn’t know about this, enjoy.

Not only can you edit videos in emacs now, but you can also create music. My initial response was WTF!? However, after watching the demo videos, I can see the practical uses.

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.

Open letter to NYSIF:

https://www.nysif.com/include/BrowserDetect.asp?browserNM=Netscape

You should be congratulated. This is a level of incompetence of which I have not seen since ’90s.

My scathing insult aside, what is that? The world has moved on. There are ther platforms out there such as OS X and Linux which have fully capable web browsers. You really should look into hiring a new web team if thats the best they can do.

This is a good idea.

Lisp Tutorial

I have been avoiding these social hype sites for a while now. I have
simply failed to see the benefit. (besides sucking yet more of my time.)

Today, stpeter posted that jaiku had a jabber interface. Anything that
allows me to quickly utilize their service via emacs is very
enticing. Since I use emacs-jabber jaiku was
simple.

While I was able to setup a profile quickly and get it setup
in jabber via xmpp:jaiku@jaiku.com I
have yet to find anyone I know on there. I have 348 people in my roster
and not one of them is on jaiku. Oh well.

I suppose the price one pays when they ignore all the social crud
crusting up the edges of the web is that they don’t know anyone
there. (Also, not blogging for a while probably might have something to
do with it.)

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.

• Use the site at http://alpha.qunu.com. This is simply a custom jabber client via html and javascript.
• Register with quser.alpha.qunu.com
• Add quser.alpha.qunu.com to your roster via a subscribe request
• Add quser@qunu.com to your roster

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

Ever wonder what the point of that rss icon in firefox is? Ever go to a blog that you know has an rss feed, but you can’t find that stupid orange XML icon?

It is suppose to make subscribing to rss feeds easier. The problem with firefox’s icon is that you can’t use anything except firefox to read the feeds. Why isn’t there a “copy RSS url to clipboard” context menu?? Features that have such great potential but fail to really do anything are worse than useless, they are frustrating.

How this little icon works is that when firefox sees a <link/> in the header part of the html page pointing to a rss feed, it turns on and allows you to bookmark it. Blarg! I would rather it just go away.

I have resorted to Ctrl+U too many times. I am quite sick of it. So grease monkey to the rescue. I hacked up a quick script that grabs all link elements in the html head and puts them in a simple drop down menu.

Give it a shot and let me know how it goes.

Script is at: http://blogs.openaether.org/data/headerlinks.user.js

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

Fred pointed me to Matt’s We Media Deal

Which is all fine and good. What I want to know is; Can I opt out?

I want another value path for the transaction. Sometimes I want to be able to just acquire the content. Especially if its something static like video or audio. I don’t want to give my soul away to watch Fubar.

The other day I got really tired of bashpodder.shell. While it is a great and simple solution, it has quite a few limitations, namely podcasts were completely separate from my regular feeds.

I like automation, I particularly like automation that I can ignore. I have been using rss2email for a while. I even hacked it to post directly to one of my imap accounts instead of bothering to go through smtp. This has worked out exceptionally well.

My latest hack on rss2email is for it to recognize enclosures (the part of rss that makes it a ‘podcast’). Its quite simple right now. You specify the directory to download to, it makes a subdir based on the feed title, and uses a configured command to download it. Like I said, quick and dirty.

An example config.py

USE_IMAP=1
IMAP_USER=”username”
IMAP_HOST=”imap.example.com”
IMAP_PWD=”password”
IMAP_ROOT=”INBOX.feeds”
IMAP_DIRS=1
USE_PODCAST=1
PODCAST_DIR=”/home/user/podcasts”
PODCAST_DFLT_ARG=”-O %f %u”
PODCAST_DFLT_CMD=”wget”
PODCAST_DFLT_WAIT=False
#tuple is:
PODCAST_TYPES={’application/x-bittorrent’: {’default’:True,
‘m3u’:False,
‘m3uregex’: (”.torrent”,”"),
‘cmd’:”ctorrent”,
‘args’:” %u”,
‘wait’:True}}

The %f is replaced with the filetype part of the url. The %u is replaced with the url from the enclosure. The args are regex’d and then spawnpve is called. The WAIT variable will determine whether spawn will block or not.

An m3u file is generated at PODCAST_DIR/year-month-day.m3u .

One thing I would eventually like to do is make the config a bit more reasonable. Mainly the PODCAST_TYPES is hairy and not really functional. The m3u file is hardcoded, which should not be.

UPDATE:
Oh yeah… how about a link to the hacked rss2email? You can find it at http://blogs.openaether.org/data/rss2email.py

Paul Tomblin is talking about learning ‘ajax’. The project he describes is quite an undertaking, and I wish I could help out. However, anyone who is learning ‘ajax’, should go read Paul Grahams essay on web2.0. Its well worth it.

We already are dealing with the fallout of our current monoculture. Why do we want another one? A good post over at http://www.concurringopinions.com/

A great post over at the Standards Consortium Blog about the latest rounds in opening office documents. You can read the whole post, which I recommend. Or you can simply look at the uml cartoon I made over at my other blog

Lets say someone starts performing fradulent transactions using your various accounts, commonly referred to as ‘identity theft’. The problem really comes in when you try to clean up your ‘reputation’ in the financial world, aka your credit report.

All this false information is being spread about you. The financial institutions are spreading lies hindering your ability to conduct business. This sounds like defamation to me. Which last I checked was illegal.

Since the fincancial world has no incentive to stop identity theft, i.e. the cost is on you not them, its going to continue ad infitum. Unless we enact yet another huge pointless undecipherable piece of legislation that no one understands. (except really large law firms).

I wonder if suing the financial institutions involved would work and if so would that stem the tide for yet another giant paper weight on the economy.

tanget:
My Aunt Tillie is scared to death of computers and refuses to use them, yet needs to make an online purchase. If I decide to help her out and use her credit card to make the puchase for her, am I an identity thief? More specifically, will any law/regulation to come out of DC account for all these myriad socially acceptable situations without being a bloated pile of crapulence?

well, almost. epic has a list by hoofnagle of ten simple things that you can do to safe guard your pivacy. Definitely worth a look