brennen
/
p1k3-wala


								<[Stephen]> A couple thoughts:


								More real-time than face to face: telepathic communication

								Less real-time than snail mail: time capsules


								My first programming was in BASIC for the Atari...800? Or 400?


								Blue screen, white text. 3-2-1 Contact Magazine had a BASIC program in the back every month.


								Do kids magazines nowadays come with programming snippets to play with?


								<[Stephen]> Cycling through input sources is how we experience our very existence. It seems understandable that we would replicate this process in microcosm. It's instinct, or even more fundamental.


								<[Brennen]> I have to think about that one.  I'm not entirely sure that _is_ what the human brain does, exactly - for one thing, there's a lot of parallel processing going on.


								But anyway, that's not exactly what I'm getting at. Sure this is a special case of something more general in attention patterns, but I think it's got properties which only really come out under the right conditions.


								<[Alan]> Surely there is an equivalent to select(3) in the human brain? Or for those of us with mad multitasking abilities, something more like epoll / kqueue?


								<[Alan]> Point is, polling is expensive. And wasteful. You go around checking for I/O availability on all these different sockets. You're literally just burning CPU cycles for no good reason. I do it / hate it too though.


								There are some notable examples in the protocols you've listed here where there is true, efficient I/O multiplexing. SMTP can block until successful / failed delivery for instance.


								Blogging, on the other hand, can't, so you have this stupid idea of an RSS feed which must be periodically polled for updates and all these retardo schemes for filtering out posts you've already seen, etc. via checksums. And then you have further retarded hacks like TrackBack pings. It's just fundamentally broken if guaranteed delivery (rather than unreliable broadcast) is what you're really after. But the web couldn't have scaled without unreliable broadcast of content. Remember they wanted hypertext links to be bidirectional at first? ;)


								It's probably only a matter of time before the periodic polling method falls over for some people. It's definitely a problem if you're trying to syndicate live news, for instance. Really, you need an Arbiter (ha ha--see my other giftfile comment) in between that keeps channels open between the interested parties. Which brings us back to IRC. It all comes back to IRC in the end. ;)


								<[Brennen]> It's funny. IRC is still the most purely pleasurable protocol to use, in a lot of ways. (And perhaps not coincidentally, one of the least structurally susceptible to spam. Centralization has many benefits.) Unfortunately, what I would term "cultural considerations" have rendered it a yawning void over the course of the last decade.


								There's suckage there too, of course, and I can't remember whether the actual protocol is painful to deal with, though I used to play with it now and again...


								<[Brennen]> Bi-directional links - There's TedNelson's "but the web isn't _real_ hypertext!" rant in a nutshell. But then Nelson didn't want the web, not really: He wanted a monopoly. And of course, if the web's architecture was radically more dependent on "arbitration", you'd get bidirectional links and guaranteed delivery practically for free.  Look at how easy that stuff is when all the text lives on your server, or what-have-you. The problem, as you say, is that you wouldn't have the web.


								<[Alan]> Is it such a yawning void these days? Not long ago I caught one of my little sisters (age 12) chatting on a web IRC interface, thinking she was just on some "chat site." She was showing me how /me works and I was like, hey, wait a second...


								So maybe AJAX will breath new life (or death) into the great underweb. There is something to be said for the fact that it is off of most people's radar. I served up over a terrabyte of classical music during the '01 schoolyear via the #mpeg3c classical list. That stuff still goes on today, only video trading has probably bumped the exponent up by, oh, 10 or so. All totally off the radar. You never hear of people getting busted for DCC serving, rarely for ftp sites.


								<[Brennen]> You've got a point. And anyway, there's such a range of IRC networks that it's probably wrong to generalize. I'm just embittered by personal experience.


								Even after I quit using IRC to interact with anyone, I was always fascinated by its copyright-infringing applications. What was the Napster model, after all, but IRC with the fserve stuff built in? I knew kids when I lived in the dorms who had spindles full of burned CDs stacked on their desks - cracked software & movies that they mostly never even used or watched. It was just currency in a semi-social resource trading game they played using mIRC. They might as well have been passing around copies of USGS data or Slovakian art films or whatever. And the scale of it dwarfed anything I ever saw on the mainstream p2p networks at the time.


								About a year ago when I was looking into setting up a little filesharing network with a few friends, I came to the conclusion that a secured IRC or IRC-alike would be as painless and useful as just about anything.


								<[Alan]> "Secured." Yes. I think a great IRC mod--which probably already exists knowing IRC--would be pgp encrypted command payloads. I'd love to say I trust the server admins, just like I'd love to say I trust gmail when I'm gchatting over ssl, but paranoia becomes a way of life, as you well know...


								You could go even farther with pgp + IRC. Server could use it to authenticate new connections (screw identd, come on). Client could also authenticate server. In the end you could squeeze out a lot of cool stuff from full duplex strong encryption.


								<[Alan]> Back to the polling thing for a sec. I used to do lots of


								  WHILE INKEY$ = "": WEND


								sort of stuff too. The fact that you were pegging the CPU didn't really matter; what other process were you stealing it from? ;)


								<[Brennen]> FWIW, I know there's an IRC-over-SSL already in existence, which presumably handles the server/client authentication stuff. SILC? Something like that, but I should be working instead of googling for this stuff at the moment. I'd rather see this stuff built on top of the existing infrastructure, tho... And IRC's basic structure has always seemed fairly amenable to hackery. (Plus I just hate dealing with SSL...)


								<[Brennen]> Right. At the time, you were operating in an ecosystem of, well, command.com + himem.sys + whatever that other one I'm forgetting was, and maybe if you were all fancy there was a mouse driver or something lurking around...


								<[Brennen]> God, DOS was such an awful, horrible, broken implentation of 10% of a misunderstanding of Unix.


								<[Brennen]> (Ok, so I'm being unfair and ahistorical.)


								<[Brennen]> I suppose what DOS actually was was the unacknowledged survival into the modern era of computing of the "operating system? we don't need no steenking operating system" paradigm.


								<[Brennen]> And re: Stephen's earlier question, I don't think kids magazines still came with code when ''I'' started playing with computers. I think I found my first BASIC fossilized in a pre-algebra textbook (and shortly thereafter in an introductory programming text that, as I remember it, assumed you were working with a teletype at best - 9x6 or so, blue cover - anyone else remember this thing?).


								<[Alan]> The problem with the ssl mod is that the payload is in plaintext while it's inflight through the server. The two client connections c1 -> s and c2 -> s might be ssl, but the server is multiplexing the plaintext around between the ssl sockets.  Hopefully this is all it's doing. It could be logging it for some later evil purpose. Or marketing Beanie Babies to you in a sidebar. ;)


								PGP payloads would be truly end-to-end encrypted between the clients. And impose no encryption load on the server, which is a huge deal for high-volume servers. You'll notice, for instance, hotmail's little trick of auth'ing you via ssl and then dropping you back to http://. Probably cost them tens of millions in hardware to make ssl the default for hotmail sessions.


								<[Alan]> I saw a reddit link months back about some semi-famous hacker who has dropped everything to develop a programming language for kids. He was concerned that there's no "easy in" for them anymore--there's no toy environments like QBasic or HyperCard or Logo.


								Or maybe it's not that there's no toy environment anymore, it's that there's too many...back in the QBasic days, there weren't too many alternatives, so there was a big community buildup around each environment. Like your QBasic experiences Brennen. I'm not sure the communities are as cohesive as that these days. There's too much gravitational attraction from the rest of the universe for the matter to congeal into its very own little planet.


								<[Brennen]> Similarly for gmail.


								Right, SSL client-server would probably be an acceptable level of security if the server was running in my living room and dealing with half a dozen clients. As a generalized solution, it blows. & of course that doesn't encompass DCC, though I assume that SILC (or whatever it's called) does client-to-client encryption.


								Seems to me like the interesting, legally safe filesharing solutions for the medium term future are built on small trust networks and carried over opaque-to-the-outside protocols. Once you're operating that far under the radar, as a matter of practicality you're unlikely to get busted. It's not like any sane ISP is going to go "gosh, that there's a lot of data transfer - we'd better make sure them boys ain't up to no good". And of course there's always the proliferation of cheap, fat physical media. "Never underestimate the bandwidth of a station wagon full of tapes."


								<[Brennen]> My own pet theory about toy environments is more that the ones kids use have all grown up crippled in the web/document space. It's not that there aren't interesting toylike environments; something like Squeak is pretty impressive, though I think it flies over the heads of 12 year olds. It's more that things like Flash or even screwing around with Myspace soak up the energies that would have gone into a QBasic adventure game or whatever.


								It's not the "no easy in" problem, exactly - it's more that what's ''perceived'' as the in is too facile. You can go down a hundred different paths that seem to lead you deeper into the machine without ever finding one that leads to hacking on anything.


								Look at QBasic: It's a fucking horrible language. But on the level that I encountered it as a kid, it was a toolbox, not a big conceptual framework--I mean, not a frame like the web, where things are fundamentally documents, or fundamentally abused documents if you're doing anything really programmatic with them.


								Sure there was scaffolding in place. But I probably didn't need to be thinking about how to ''implement'' graphics primitives or strings or whatever. I never would have gotten that far on my own - hell, I never have and likely never will get that far - but I think it did me good to be thinking on a level at least as basic as "I am setting a screen resolution and changing the color of pixels". Who sits down to put something in a web browser and has to think in terms that fundamental about what the machine is doing?


								<[Brennen]> Back to the secure IRC thing, [http://en.wikipedia.org/wiki/SILC_%28protocol%29 SILC (protocol)]:


								:SILC channels (groups) are protected by using symmetric channel keys. It is optionally possible to digitally sign all channels messages. It is also possible to protect messages with privately generated channel key, that has been previously agreed on between channel members. Private messages between users in the SILC network are protected with session keys. It is however possible to execute SKE protocol between two users and use the generated key to protect private messages. Private messages may be optionally digitally signed. When messages are secured with key material generated with SKE protocol or key material previously agreed on (for example, passphrases) SILC provides security even when SILC server may be compromised.


								Looks better than I remembered.


								<[Alan]> Yeah, sounds about right, but why do we need more acronyms, more key exchanges, more authentication procedures, more protocols here? Why couldn't we layer existing public key infrastructure on top of it on the client ends, rather than *needing* a SILC server? Aside from the basic authentication and authenticated message routing afforded by pgp keys, the server shouldn't care about the message payload: it could be plaintext, or it could be pgp-encrypted for the recipient. Recipient decides and acts appropriately. It's application layer.


								I guess the main reason why this is not done usually is that asymmetric encryption is slow. When speed is important, you use it to set up a much faster symmetric channel--I see SILC is doing this. But chat isn't really speed sensitive on the client end. Realtime video conferencing, ok. Maybe that is SILC's target application now.


								There is apparently a draft of TLS (the artist formerly known as SSL) which can exchange [http://en.wikipedia.org/wiki/Transport_Layer_Security PGP key certs instead of x.509 certs] during the handshake. Do you realize how awesome this would be for PKI? Instead of paying $2000 to VeriSign just to be able to say "Hey, I'm Brennen," we just have a few key-signing parties once in a while, choose who we trust and who we don't, and the trust structure just emerges from there. "Certificate Authorities" become "people who have good judgment, in my judgment." ;)


								<[Brennen]> "why do we need more etc." - well, exactly. I remember doing a little hack expanding on someone's trivial (not quite as trivial as rot13, but at that end of the scale) little mIRCscript code generator to pass messages in IRC channels as an end run around a crippled server that wouldn't permit most operator modes. People with the day's "key" saw plaintext, everyone else got pissed and left. At the end of the day, given what IRC & DCC between them already do, I'm not sure it ''needs'' to be much more complicated than that (obviously it needs to be done with real tools), though I understand the appeal of building it the 'right way' from the ground up.


								Re: PGP key certs, what an incredibly good idea. I cannot even say how much I despise the concept of CertificateAuthorities.


								Somebody on the LUG list here was talking not that long ago about an alternative authority that worked on kind of a grassroots model. Digging around, here it is:


								:For those not in the know, CACert is another certificate authority, using a more grassroots approach than Verisign or the like.  It uses a web of trust to certify people for SSL web server certificates and the like, e-mail, etc.  By using assurers located around the world, kind of like "digital notaries", you can meet up with other local people in your area and get certified.


								They're at [http://www.cacert.org/ cacert.org]. This strikes me as a should-be-unnecessary social hack for a badly broken technical architecture.


								<[Brennen]> (Unless of course these *are* the folks doing PGP and it's not as overcomplicated as it sounds initially, 'cause it's not like I went and read their actual documentation.)


								<[[Alan]]> Yeah I've been using cacert.org for a while now on thegotonerd.com. It's x.509. They're about the nicest CA you'll find but I'm not sure they're anywhere near being trusted enough to be included in a browser.


								They also only issue sign for very short-term periods, I think 6 months, and then you have to go renew. Which is fine, I think that helps with the "getting trusted" issue.