A bit nuts, but very, very smart.

I am NOT going to use this whack theory to justify frame- and applet- based website navigation.

READ AND UNDERSTAND:

"Any time you engage with information, the reality that you extract from that information is shaped by the tools that deliver it. Microsoft’s information presentation is such a monoculture that it edits out a lot of other realities. So you have a new kind of monopoly that affects the way people think in ways that are invisible to them.

...

You now have two distinct ways of gathering information beyond what you yourself can experience. One of them is less a medium than an environment -- the Internet -- with a huge multiplicity of points of view, lots of different ways to find out what’s going on in the world. Lots of people are tuned to that, and a million points of view have bloomed. It creates a cacophony of viewpoints that doesn’t have any political coherence at all, a beautiful melee, but it doesn’t have the capacity to create large blocs of belief.

The other medium, TV, has a much smaller share of viewers than at any time in the past, but those viewers get all their information there. They get turned into a very uniform belief block. TV in America created the most coherent reality distortion field that I’ve ever seen. Therein is the problem: People who vote watch TV, and they are hallucinating like a sonofabitch. Basically, what we have in this country is government by hallucinating mob."

So says John Perry Barlow.

XMPP, data transfer etc., redux

OK, so where I'm coming from:

Firstly, this post and the one below are tangentially related to Volity, but I should emphasise that I don't hack on Volity myself - the hard-working Volity coders being Doug Orleans, Karl von Laudermann & Jason McIntosh.

Secondly, these are just my serialized brainstrikes on how I riff on the whole "XML documents <-> XMPP" shebang, which is my approach to the whole idea of taking the web as a quantum leap in data density, and looking to build on that in line with the whole idea of navigable info/dataspace as an end-target.

I should mention that my next idea is to try and get the whole Gradient system working with an HTML viewport as opposed to SVG.

• I want to get surfable pages that do things like Gradient out there - this is a next-level leap in the capabilities of hypertext systems, and it's possible to do right now - preferably without any client-side installation (see below 'graphs & posts for ideas)
  
  
• The JEPs for file transfer via XMPP are, as far as I can see (and someone please correct me if I'm wrong) targeted at P2P use cases, and if one of the XMPP clients becomes a "server" of documents and starts receiving 1000 requests per second, the XMPP server starts to ask questions like "Why God WHY?!", and with good reason.
  
  
• Fortunately, we already have HTTP, which scales better than the (admittedly nonstandard) method of inserting an XML document as the child element of an IQ RESULT stanza that I use in Gradient.
  
  
• Volity are using HTTP for file transfer, and this is eminently sensible.
  
  
• HTTP can't do the kind of things XMPP can do to markup (with the help of Gradient), which why both Volity & Gradient implement two different solutions for doing the interactive & dynamic stuff. Apart from broadcast, server-client RPC is one of the things that is technically possible using some kind of hack to add a callback function on a client using the newly-crossplatform SOAP ECMAScript objects and/or the DOM3 load/save functions, but this is not exactly the most elegant of solutions, to put it mildly.

THEREFORE, and taking into account that we want normal web-pages to be able to enhance themselves using this stuff while remaining accessible to normal users, it seems reasonable to do something like this:

a) Joe loads his HTML page via HTTP.

b.i) (client-side mod) A Mozilla extension either (a) looks for <meta name="gradient" value="user@xmpp-server.example.com/index.html"> or (b) Looks for <gradient:service gradient="http://foo.com/blabla" jid="user@xmpp-server.example.com/index.html">, and upon finding one, connects to the server and does the twist using some as-yet-unspecified-or-standardized XMPP extension.

b.ii) (no installation necessary, not sure if possible) page includes an applet (up: I needn't code C++, down: applets.) that is given a reference to the Document and plays with it like so. Not entirely sure of the security issues, it's all doable.

I know that from the PoV of a web designer, webmaster, information architect or usability engineer that applets suck, admittedly, but imagine a sidebar/frame applet that (a) has a decent dynamic ToC as per the Weblogic 8 admin tool, (b) decent site-search/index as per RoboHelp, (c) IM interface letting you chat/collaborate with other surfers as per Lluna, and enables your currently viewed document to be updatable in realtime etc. etc. etc.

(I know frames also suck in general but this frame is in lieu of a Mozilla sidebar)

So, if this is the grand vision, why did I start muddying the crystalline waters of disco? My somewhat hazy vision of disco was as defining a set of IQ's for querying a hierarchical nodeset. For each page or each site that has this something like this, the client would want to know (e.g.) do we support site chat using the Lluna extensions, do we do MUC, do we have a ToC (which would be a disco tree) for the site, etc. At which point we're kinda blurring the semantics between site "features" and site "services".

File transfer & XMPP

An interesting thread got started on volity-devel on how to do file transfer using disco & HTTP. [update: see this post for a correction] Right now, Gradient file transfer is basically an ugly hack, with a transposition of the HTTP paradigm ontop of XMPP, which leads to scaling problems.

There's a couple of influences on my direction here.

Firstly, surfing via XMPP is never gonna happen in a big way - HTTP is too entrenched - so the obvious step is to enable Gradient-style extensions to webapps by including a JID/disco node ID etc. in a meta tag or namespaced head child.

This means I should either squeeze a Gradient into an applet, in which case any web-page could become a gradient-page, or fiddle with the internals of Mozilla, using the XPCOM XMPP client or something like that to construct a second Gradient client in the client-side Mozilla environment, i.e. using either the XP C++ dialect or ECMAScript. This would dificult, to put it mildly.

Secondly, disco is quite obviously the right way to do view/game-specific feature discovery & [meta]data publishing in Volity, and in a broader environment has a variety of uses, which I will enumerate briefly when I finish this post tomorrow.

It seemed like a nice idea

So I was looking at the Conway's Game of Life implementation of a Turing machine, when it struck me: a network of BF interpreters with inputs feeding into outputs, all working on the same tape, arranged into a grid pattern:

• one tape passes through N nodes as instructions, and M nodes as data.
• various configurations are possible, not just grids. It's network topology 101.

BF has 8 instructions, meaning 3 bits are needed - octal. I could add a ninth instruction 'X', that switches the input and instruction streams. This would mean using 4 bits - hexadecimal nibbles - with another 7 instructions free.

Each node would need to wait & notify based on input, instruction availability. The whole thing would be visualised fairly easily.

BF operates like a Turing machine, and has:

• one random-access storage medium - the tape
• one standard input
• one standard output
• one instruction stream

That's 5 in total. If we limit the alphabet, the input and outputs could also be composed of BF glyphs, meaning the tape would be glyphs also.

But would it make any sense? Why do this?

• There's already a Conway's Game of Life Turing machine.
• Why not a BF interpreter constructed using a cellular automaton?
• Would the rules underlying this cellular automaton run on top of a nanoscale substrate?
• Could we have nodes etched/sketched in substrate and then layered (for redundancy?)

This would give us a very large cluster of very stupid computers that are almost impossible to program, but might exhibit interesting emergent behaviour.

Problems:

• when (if) we switch data and execution inputs, what happens to the stack?
• If we add an X instruction, can we wire the output to the input and generate our own code?
• How do we program this thing? BF is a pain to begin with:
• 
  
• should we find a nicer, yet equally small syntax?
• should we compile a macro language?

• What happens when two nodes modify the same glyph on the tape?
• How do we get the thing started? can we make a pseudo-random code generator in BF?

Etc. A potentially cool hack with near-zero real-world applications, short of sci-fi equiv. imaginings.

I am Disconnected.

Jeez this is frustrating. The place I moved into used to be an office, meaning (up) there are strips along the wall with power and phone lines (beaucoup des plugs) , but (down) when they left the premises they not only disconnected the line but physically cut it too (je n'ai pas un connection d'Internet) which means that I have to either wire things or pay someone else to do it. Merde.

Welcome to the neo-luddite world of the Offline. Next thing you know I'll have brought a TELEVISION.

• I am trapped in a box.
• It is quiet. Too quiet.
• I have lots of spare time.

The problem with KISS

Is that you can KISS yourself into a corner, and when you get there, you'll realise that some serious pain is in order.

The formerly-scary technology known as RFID

"The street finds it's own uses for things"
- William Gibson

Surprise surprise, some RFIDs are hackable. Very easily hackable.

RFID is a corporate technology borne of corporate needs & requirements. But like any tech, it will get taken and used / abused by people in ways their creators never envisioned, in ways that may well be highly creative, disruptive, destructive, or subversive.

For me, hi-tech is best when it's all four.

Moving

A speculative yet interesting theory.

Moving from totally furnished (down to the kitchen utensils) to unfurnished (as in "the workmen just finished installing the sink") makes you realise: (a) how many possesions you have, (b) how many more you need.

Door stops. Kitchen towels. Coat hooks. Spoons.

The problem as stated by Jack, was that the things you own end up owning you. Flexibility is a product of what is not yet present, not that which exists already.

Deduction: I need to start getting rid of stuff. So far, I can think of these:

- extra computers
- books

Also: Gaping Void.

The worst thing, recap

Summarised, the issue is seeing the potential for elegance. From elegance flows stability, flexibility, extensibilty; beauty. How could I not do this? It goes against my nature.