What is Fritter?

Fritter is (well, will be) a program that supports Twitter-style microblogging over Freenet. It is designed to be very simple, both to use and to implement, very fast, and support anonymous, censorship-resistant speech thanks to the underlying Freenet architecture.

The name

It's been suggested that I find a new name. Something less Twitter-derived. I'm taking suggestions. I'd like to choose a final name fairly soon, so I can include a shortened version in some of the protocol strings.

Alternately, if you can say with some reasonable authority that using the name Fritter is OK, that would make me very happy. I like the name Fritter. Not being a lawyer, or even particularly well versed in trademark law even by IANAL standards, I can't say that it's ok to use the name.

FAQ and RFC

The old text of this page has moved to the FAQ and RFC page. It includes things like protocol details and what the heck Fritter actually does.

News and updates

Edition 2, 20090724

Current status: I have a very crude version working as an HTML-interface Fred plugin. It sends compliant frits, and watches a specified set of SSKs for frits. It doesn't do any of that fancy AJAXy notifications stuff, it has no mechanism for finding new users, it does not support links, and it does not support any Fritter protocol files other than frits. It also does not save any information (like your identity and SSK keypair) in a persistent fashion. It is likely to fail silently (or with log messages at loglevel minor if you're lucky) if given input or files it doesn't expect, but I hope it's unlikely to break badly. In short, it's not yet ready for an alpha release. However, I'm going to put the code up here anyway in case someone feels like playing with it. Warning: you probably don't actually feel like playing with it.

About the only thing the current version is useful for is testing the messaging latency. Right now, typical numbers appear to be 15 to 40 seconds, though I've seen less a couple times. About 30 seconds seems very common. I've seen much longer times, though only rarely (once almost 30 minutes). This is for Frits where the request was started before or simultaneously with the insert; as that is the normal mode of operation for people you're actively following, that's what I care about.

I think this testing has exposed a bug in Freenet. If you add your own SSK to the watched users list, you'll see your own Frits. I would expect that when you post a frit, it would very rapidly hit your own node's datastore (or client cache, in the near future, or if you're using trunk), and then the fetch would succeed. However, what appears to happen is that the insert gets sent out over the network, eventually completing 10-40 seconds later, and giving the completion message (see log, message isn't displayed in Fritter). Only then does the fetch complete. I suspect that the problem happens out on the network as well: my node sends to node A, sends to node B, to node C, etc. The person watching for my frit set a request out from their node, which got routed to node C and then along roughly the same path as my insert. In theory, my insert should hit node C, which should immediately return the data to the requester, without waiting for the insert to complete. In practice, I suspect the same thing happens as when watching local inserts — it doesn't complete until the insert finishes. Assuming that routing works, the two paths should cross long before the final hop of the insert happens. Waiting for that final hop to happen and the ack to come back is likely killing the request latency. It also probably increases network overhead: it would be cheaper for C to cancel the request it sent out than for the node it sent it to to send the data back.

I wrote a somewhat (more than somewhat?) ranting email about the lack of documentation on the Freenet code. Basically, Freenet is sufficiently poorly documented that it makes writing a plugin more time-consuming than it should be.

You can find the current version of the code here. There's no user documentation outside of the Javadoc. I recommend you either read the source and Javadoc, or just click some buttons to see what happens. Don't expect too much.