Samizdat: Building the anti-Facebook
2. Exploring the constraints
Samizdat: a quick recap
In the previous article, which, like this one, is aimed for an interested but non-technical reader, I introduced the name Samizdat or S for the anti-Facebook.
S should allow communication with people, and also blocking them; it should be free, and easy, and have a positive network effect.
S should require no crowd (so useful even just for one person) and no real name, no server or proprietary software or protocols. Updates should not happen continuously but discretely in individual chunks — and no ads.
These constraints have significant consequences for the design of S — to the point that very few solutions are possible. Constraints are a good thing: they clarify your thinking and force you to simple and more robust answers.
Quick digression: where’s the UI?
Everyone asks this, and it’s very reasonable, but the UI appears at the end!
We’re working backward from some very stiff constraints, and all theirs logical consequences need to be worked out before finally putting a skin on it.
A metagoal: the least amount of programming
Many brave groups of programmers have started off to make some sort of collaborative social system but never completed the task because it was too large.
Facebook has 62 million lines of code. You wouldn’t know it from this boring, amorphous, uncustomizable stream of consciousness that is 98% of what it offers you, but we are told this is so.
Since we are trying to invert as much as possible from the Book of Face, we should have a goal of writing the least code possible.
The less code that needs writing, the more likely it will all get written.
In fact, I’m going to aim for zero lines of code — to see if some plausible implementation could be accomplished using no actual new code but just existing programs and some document explaining how to hook them up.
I suspect not, but every word is like an unnecessary stain on silence and nothingness, so we should try to keep the coding down to a dull roar.
About Worker
To give you your social network, some program is running on some computer somewhere, sending, receiving, processing, storing and retrieving data
In Facebook’s case, it’s an unknown collection of a large number of programs running on real or virtual servers in an unknown location.
But S has no servers — it must somehow be run by the user. Yes, I’m fully aware this is a big barrier to entry, but certainly not insuperable.
Again, to use Samizdat there must be a program running on the user’s machine. Let’s call this program Worker or W.
The Samizdat system is just one or more Workers running and perhaps communicating, not necessarily continuously, or at the same time, or regularly, or predictably.
Worker stands alone
It would be very nice if W could run entirely in the browser, but W needs the ability to read and write disk data at the very least, and probably to make network connections.
This means that W has to be a stand-alone program — which means it must be installed by the user. Yes, I am very much aware that any installation step, no matter how painless, will lose 90% of the audience, but the apathetic 90% wouldn’t use anything new anyway. (And there is no other solution anyway, given our constraints. If it’s going to be free, and there are no ads, someone has to own the computer that runs the program.)
Where is Worker?
Now we know that W is a standalone program, how do we interact with it? Where is Worker’s user interface going to be displayed?
Drawing pages on the screen, handling mouse and keyboard input: this is a lot of code to write, particularly to get it right on every computer. Let’s not do that. Let’s leave that part to an existing program which does this really well — the browser!, your familiar old Mozilla or Chrome or Safari or your choice.
For the programmer, this is easier. You use W like any other active web site — except that the web pages are served from your own machine, to your own machine only. This is a very plain, regular way to build a program — twenty-year-old technology. (The details of implementation are unimportant though I’m leaning to Python and Flask.)
What is Worker working on?
W’s primitive data, the fundamental building blocks, are “everything the browser does”, so images, plain text, “web pages” (HTML, JS, CSS and JSON), audio and video files.
This primitive data need to be organized somehow. Since we want to do as little work as possible, that organizational system is just a directory structure — files in a file system.
“A fun puzzle for the reader”
Very many years ago, I bought a beautiful origami book which, as many of the best are, had text only in Japanese.
It contained a fascinating one-piece 3D geometric model which was both concave and convex.
The diagrams led you step-by-step through careful folds — to a flat sheet of paper with many creases on it. Then there was a paragraph of Japanese, and a picture of the final model.
I desperately wondered what it said. I tried several times over several years to make this, and finally I succeeded. Years later I had a Japanese friend over and I asked him to tell me what it said. It was some pleasant musings, and then instructions: “The final construction of the model is left as a fun puzzle for the reader.”
There is enough excitement in this article for you, Gentle Reader, to chew on.
So I’m going to recap what we know so far, and then, if you are a technological type, let you think about a possible answer.
Samizdat is one or more Workers, little programs that run on people’s machines and display web pages in the browser. These pages are build up of primitive data which are images, text, HTML, or anything else you can show in a browser.
Somehow the user needs to to keep track of all this data, edit it, display it, share it with others, and we want to write as little code as possible, none if we can.
In our next thrilling episode I will reveal what the overall solution is, what the actual existing implementation is, what would need to be done to get it actually working for this task, and why I’m not entirely sure I’m going to do that work. So stay tuned!
