[Blocks-development] Strange direction for Blocks: "building-blocks" :)

[Michael S. Jr. <bl...@ms...>]

OK, I had a crazy idea.  This might not be appropriate for Blocks, but it's
certainly relevant to the problem Blocks tries to solve.

Idea in short:  filesharing system is specified in layers roughly according
to the OSI model.  Each layer is specified by an interpreted scripting
language.

Detail:

Like any other filesharing program, this would have an interface for
connecting to the network, searching, downloading, uploading, chatting, and
anything else people can think of.  All of these things are abstracted --
the user doesn't need to know they're communicating with a Napster or a
Gnutella or a Blocks network.

Under the surface, though, the program is using scripted code to work with
each layer of the system.  These scripts have been designed by someone who
is *not* the end-user, and they enable the program to talk to different
networks.  Each script represents a part of the system according to the
seven-layer OSI burrito -- network, protocol, session, application, etc.

This system is beneficial so far because it allows you to easily connect to,
search, and download from multiple network types from one interface.  When a
new network type becomes popular (MojoNation?), simply add scripts for it.
When a proprietary network service tweaks its protocol a bit to break
existing clients, simply tweak your scripts a little bit to match.

The scripting language is what makes this system interesting.  Has anyone
seen Nessus?  It's an open-source security scanner that specifies attack
probes with a custom scripting language called NASL.  You script the attack
with NASL -- what to send, what to expect to receive, what to do in case of
any of a number of responses, etc.  Let's imitate them.  :)

Even though network system design is pretty far out of the reach of most
end-users, I believe the scripting language should be transparent enough for
end-users.

In text form, I imagine the scripts will be BASIC-like (yes, the language
BASIC) and use a very simple set of commands specific to the kind of script.
 In the case of protocols, the script specifies which messages can be
passed, and what the internal format of the messages will be.  For sessions,
the script specifies what actions are taken when each message is received.
(I imagine session and application code will be algorithmic and complex, so
an elegant task-specific language is called for.)

In GUI form, I imagine we can create abstracted pieces and join them
together like flowchart boxes, lego bricks, or any other UI metaphor you
prefer.  Very Hollywood-looking.

If properly implemented, the system gets some interesting properties:
  *  Interoperability with multiple networks and systems!  Want a program
that seamlessly integrates with Napster, iMesh, Gnutella, Blocks, and IRC
channels, with one search interface and one upload/download interface?
Download the program, customize as needed, and you're all set!
  *  Protocol designers who can't code can now design and test new systems.
  *  Therefore, the system can face new threats and new network demands more
rapidly.  Any power-user can make changes:  implementing IRC-style queues in
Gnutella, for example.

Cons?
  *  Chaos!  Ten million little protocols, each with enough insignificant
differences to make them incompatible.  Hmm...maybe we can implement code
signatures and version control.  We need to prevent Joe Sixpack from making
a random change to something and not knowing why his program doesn't work
any more, while still allowing people who know what they're doing to make
necessary design changes.
  *  Script-kiddie heaven!  Attackers can use the network against itself.  I
think there's a 'security-through-obscurity' argument in here somewhere.
This will cause the buggy networks to die and the healthy networks to
thrive.

What do you guys think?

--Michael Spencer
bl...@ms...