Re: [9fans] The Plan 9/"right" way to do Facebook

[Winston Kodogo <kodogo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 15805 bytes --]

That's an awfully long troll. Some people have a lot of time on their
hands. And it's not yet April Fool's day, even in New Zealand.

On 31 March 2016 at 12:40, <cigar562hfsp952fans@icebubble.org> wrote:

> Greetings, 9fans!
>
> We all know that Plan 9 started as a retrospective "re-take" on UNIX,
> occasionally referred to as "UNIX done right".  This has led to
> differences between "the Plan 9 way" of doing something vs. "the UNIX
> way" of doing it, such as those highlighted by the infamous "Unix to
> Plan 9 command translation" page on the Plan 9 wiki.  More generally,
> this can be viewed as the difference between the "right" way to do
> something versus the "popular" way to do it.
>
> So, my question is, what would be the Plan 9/"right" way to do Facebook?
> Stated differently, if social networking were to be re-imagined and
> re-done "right" this time, how would it be done?
>
>
> E-Mail
> ======
>
> The obvious answer that comes to mind is e-mail.  It worked well for
> decades.  Although 9fans appear to continue this tradition in grand
> style, using e-mail for social networking poses a number of problems:
>
> 1. _Spam.  The fact that SMTP doesn't authenticate senders of e-mail
>    messages has led to a proliferation of spam which has greatly
>    burdened the medium, requiring complex workarounds that usually put
>    legitimate mail at risk of misclassification as "junk".
>
> 2. _`Subject lines`.  Few people seem to know how to choose an
>    appropriate "Subject:" line, anymore.  People will use subjects like
>    "tonight's meeting", without specifying what group is meeting, when
>    the meeting is, or what it is about.  When the topic of a thread
>    drifts from its original topic, few people remember (or even think)
>    to update the Subject: line.  Often, when one person wants to send a
>    second person an e-mail, the first person will simply reply to the
>    last message they received from the second person, even if it was on
>    a completely different subject.  (This, of course, creates false
>    relationships between the Subject: and References: fields used to
>    define threads.)
>
>    Despite the fact that most MUAs (including Webmail_) offer the
>    ability to automatically sort e-mail into different categories, many
>    people don't know how to sort incoming mail.  When they get too much
>    e-mail in their "Inbox", the become annoyed and confused.
>
>    These problems were addressed, somewhat, by the advent of the Web
>    forums which were popular in the 2000's.  On a Web forum, moderators
>    could reclassify posts and reorganize threads to better reflect their
>    content.
>
> 3. Listservs.  For people familiar with mailing lists, sending commands
>    to list servers is not difficult.  Unfortunately, many people don't
>    understand listservs, and want some way to subscribe to and/or
>    unsubscribe from mailing lists using a Web page.  While some
>    listservs provide a Web interface in addition to an SMTP interface,
>    it is becoming more and more common for mailing lists to append
>    footers containing "unsubscribe" links.  This information (which
>    usually duplicates information found in message headers and should be
>    obvious to anyone who knows how to use the listserv, anyway) pollutes
>    the content of the messages.  Furthermore, if a message containing
>    such links is forwarded to someone else, the final recipient could
>    unsubscribe the forwarding party from the list without his or her
>    consent.
>
> 4. _`HTML mail`.  Nowadays, people will write things in e-mail messages
>    like, "I've highlighted the changes in red".  On my display, plain
>    text is rendered in black-on-white!  Or they'll write something like
>    "here's the link," without specifying any URL.  You have to dig into
>    the text/html part to find it.  Forwarding an HTML message to other
>    recipients can also pose security risks, if _hyperlinks in the
>    message offer access to personal information.  HTML mail also makes
>    e-mail messages five times the size they need to be.
>
> 5. MIME.  It's great to be able to attach small files to e-mail
>    messages, but there are WAY too many people who will just blindly
>    attach Word Perfect, Microsuck Word, or ZIP files to their messages.
>    I've even seen otherwise "well-educated" lawyers do this.
>
> 6. Large attachments.  MIME permits relatively small files to be
>    attached to messages, but it is not really meant for distribution of
>    large _files such as large images, audio files, movie files, ISO
>    images, or tarballs.  For people like us, that's not a problem; we
>    just upload the file to a server and post its location, along with a
>    brief description of the file.  People who do not know how to do this
>    will typically end up jumping through hoops to upload their file to
>    some dreaded third-party service like Flickr or YouTub, and then post
>    a link to that.
>
> 7. _Quoting.  Very few people use Usenet-style quoting, anymore.  Often,
>    people will quote the entire message to which they're replying, and
>    use vague English phrases (or even in-line "quotes") to indicate to
>    what points they're replying.  When top-posting became the default
>    quoting style for Outlook, e-mail became all but undecipherable.
>    Have you ever seen an e-mail containting five "Original Message"
>    lines?  There can only be ONE "original" message!  Have you ever
>    tried to respond to a top-posted message using Usenet style quoting?
>    Have you ever tried to read a thread using a mixture of different
>    quoting styles?  It's just a CF.
>
> 8. Paragraphs.  There is this thing, called a "paragraph", which people
>    used to learn about in school.  The _paragraph is a great tool for
>    structuring content, enabling an author to group related information
>    together, and to separate it from content of a different sort.
>    Nowadays, many e-mail messages are written on a single line (often
>    even without word wrapping), without regard for any logical division
>    or organization.  When paragaphs are used, they are often used to
>    repetitiously reiterate the content of preceeding paragraphs.
>
> 9. Text messaging.  Because text messaging and e-mail are both
>    accessible from modern phones, people have begun to treat them as if
>    they were the same medium.  They are not!  People are now reading
>    e-mail messages using cultural conventions from the "texting" world,
>    rather than understood e-mail conventions, and mis-interpreting what
>    e-mails say.  People are also writing e-mail messages as if they were
>    texts: have you noticed how "A.M." and "P.M." have now almost
>    universally become "am" and "pm"?
>
>    People are also beginning to expect that their e-mail messages will
>    be delivered to their recipients in the space of just a few seconds,
>    like text messages are.  Oblivious to the fact that people don't
>    necessarily even check e-mail every day, they seem to assume that
>    anything they send is going to be received more or less instantly.
>
>    Text messaging has also conditioned people to expect all their
>    messages to be short.  This conditioning has gotten to the point,
>    now, that people will consider an e-mail message longer than a single
>    paragraph_ to be "long"!  (Certainly, the present post to 9fans would
>    be considered epic-length, by that standard!)
>
> 10. Censorship.  Many groups _want some way to censor messages sent to
>    other members of the group.  While mailing lists can be moderated, it
>    generally requires one or more moderators to _`proactively screen`
>    and approve each message before it is relayed to other subscribers.
>    Once a message is delivered, it can't be un-sent.  This limitation
>    was also addressed, to some extent, by Web forums.  On a Web forum,
>    users are often able to _`flag posts` which are spam_ or violate some
>    specified "_`acceptable usage`" policy, and moderators are able to
>    edit or remove other users' posts.  Because Web forums store posts on
>    the server, and don't offer means to _`cryptographically sign` posts,
>    a user's words can be changed without them (or anybody else) even
>    realizing it.  Most Web forums also allow a user to edit or remove
>    their own posts, complicating historical perspectives on who really
>    said what.  (Think of forum posts quoting other forum posts.)  For
>    some people, the ability to alter or censor published content is a
>    _feature.  For others, it is a _defect.
>
> 11. IMAP quotas.  Many people leave their mail on their mail server and
>    just access it using IMAP.  When their mailbox quota gets consumed,
>    messages sent to them will bounce, or cannot be filed correctly by
>    the recipient.  I remember seeing a local city councilor who was so
>    popular that her mailbox filled up, at which point she could no
>    longer use it to communicate effectively.
>
> 12. _Webmail.  For starters, many people simply don't know the
>    difference between e-mail and Webmail.  When using Webmail, mail is
>    kept in the possession of a third party.  It makes it much more
>    difficult to employ e-mail encryption, such as OpenPGP.  Webmail also
>    encourages use of `HTML mail`_.  Have you ever received an e-mail
>    message containing just a URL which you are expected to "click",
>    without any further explanation?  By promoting the assumption that
>    e-mail is always accessed on the World Wide Web, Webmail promotes
>    this kind of Web-snobbishness.
>
> 13. E-mail is not stupid-compatible.  Participating effectively in a
>    community using e-mail requires a certain level of education.  Each
>    September, when a new crop of college students first gained access to
>    e-mail, there would be an observable decline in the quality of
>    e-mail.  Gradually, the situation would improve, as these students
>    began to learn proper netiquette.  When AOL began offering Internet
>    mail to its subscribers in September of 1993, however, there was a
>    decline in the quality of e-mail from which the Internet never
>    recovered.  This has been known as "The September that never ended".
>    With the rising popularity of text messaging and mobile e-mail, this
>    situation has grown progressively worse.  Now, droves of children and
>    grandmas are getting access to e-mail without any of the requisite
>    education.  This present state of affairs could, in a sense, be
>    called "The September that never ended, that never ended."
>
>
> Web Forums
> ==========
>
> Many of the problems associated with e-mail were, at least partially,
> addressed by the the Web forums which were popular in the 2000's.  (The
> classic example is the Simple Machines forum software.)
>
> A. As described under `subject lines`_, above, Web forums allowed
>    moderators to reclassify posts by subject into organized threads.
>
> B. Users could `flag posts`_ as spam_ or as violations of `acceptable
>    usage`_ policies, avoiding the need for moderators to `proactively
>    screen`_ messages.
>
> C. Users (and moderators) could edit or delete posts (which could be
>    considered a feature_ or a defect_, as noted above).
>
> D. Users could upload or post references to multimedia files_, such as
>    videos, with their posts.
>
> E. Forums offered sensible quoting_ mechanisms, as well as the ability
>    to include hyperlinks_ and to specify font colors, sizes, and styles.
>
> F. Web forums were also fully stupid-compatible.  They offered graphical
>    editing capabilities, so knowing the syntax of a particular forum's
>    mark-up language wasn't necessary in order to make a post.
>
> Forums, however, also had their share of shortcomings:
>
> a. Web forums were stupid-compatible, but smart-incompatible.
>
> b. Data was kept centrally, on a server.
>
> c. Each forum was on a separate Web site, with separate accounts.
>
> d. Using them required a Web browser with access to the World Wide Web.
>
> e. Posts could be sensored (a feature_ or a defect_, as noted above).
>
> f. It was difficult to `cryptographically sign`_ posts.
>
> g. Forums had no obvious analogue to the RFC 822 Message-id header,
>    making it difficult to identify individual posts.
>
> h. The proliferation of different mark-up syntaxes used by various
>    forums made it difficult to remember which syntax you were supposed
>    to be using at any given time.
>
>
> Social Networks
> ===============
>
> The technology that's been displacing e-mail and Web forums over the
> past decade or so is, obviously, that nebulously nefarious Medusa known
> as "social networking".  Of course, there's no need to describe how
> backwards and awful today's social networks, such as Facebook, are.
> There have been several attempts to create "open source" social
> networks; the most successful to date has probably been _`Diaspora*`
> (http://diasporafoundation.org).  Diaspora* solves many of the
> aforementioned problems, such as ensuring privacy and control over your
> own data.  Because it's Free Software, it's also smart-compatible.
> However, it still has significant limitations:
>
> I.   Diaspora* cannot easily be used to create "groups".
>
> II.  Content published on it cannot be removed, edited, or censored (if,
>      indeed, that's something you want_ to be able to do).
>
> III. It uses a push mechanism for distributing updates, so it cannot be
>      used in disconnected operation, like a MUA can.
>
> IV.  It is a Ruby/Rails application.
>
>
> The Plan 9 Way
> ==============
>
> So, if social networking were to be re-designed from scratch, all over
> again, "the Plan 9 way", how would it be done?
>
> Obviously, the network would present itself as a file system.  :D  I
> should be able to browse and post content using shell commands at the
> command line.  Or, I could use the Acme plug-in to automate the process,
> just like using Acme Mail.  I'd be able to batch-up incoming or outgoing
> changes using tar(1) or hg, so I could work disconnected from the 'Net,
> too.  But... here's the tricky part...
>
> It would have to be both stupid-compatible and smart-compatible at the
> same time.  Perhaps there would be an HTTP server which would translate
> between the file system interface and some flashy Web interface
> reminiscent of Facebook or `Diaspora*`_.  Of course, the HTTP server
> would offer some sort of click-tracking advertising framework, so that
> the HTML view of your social life could be packed with ads by whatever
> company you've chosen to host your profile.  Maybe that HTTP server
> would be written in Limbo, so it could be run on Plan 9, Linux, Mac OS,
> or Windoze.  Meanwhile, power users could fly right in, under the HTTP
> layer, and access the file system using 9P, Acme, or whatever their
> perferred tool may be, without having to deal with all the HTML cruft.
> A social network has to be stupid-compatible if it's going to be
> successful.  But it also has to be smart-compatible, i.e., done the
> "right" way, if we are to keep from going insane.  ;)
>
> --
> +----------------------------------------------------------------------+
> |           human <cigar562hfsp952fans@icebubble.org>                  |
> |Any sufficiently high intelligence is indistinguishable from insanity.|
> +----------------------------------------------------------------------+
>
>

[-- Attachment #2: Type: text/html, Size: 17816 bytes --]