- -

Design Mistakes

-

Is Gossamer Up?

-

@megtastique points out that two factors -doom the whole design:

-
    -
  1. -

    There's no way to remove content from Gossamer once it's published, and

    -
    2. -
  2. -

    Gossamer can anonymously share images.

    -
    3. -
-

Combined, these make Gossamer the perfect vehicle for revenge porn and -other gendered, sexually-loaded network abuse.

-

This alone is enough to doom the design, as written: even restricting the -size of messages to the single kilobyte range still makes it trivial to -irrevocably disseminate links to similar content.

-

Protected Feeds? Who Needs Those?

-

Gossamer's design does not carry forward an important Twitter feature: the -protected feed. In brief, protected feeds allow people to be choosy about who -reads their status updates, without necessarily having to pick and choose who -gets to read them on a message by message basis.

-

This is an important privacy control for people who wish to engage with -people they know without necessarily disclosing their whereabouts and -activities to the world at large. In particular, it's important to vulnerable -people because it allows them to create their own safe spaces.

-

Protected feeds are not mere technology, either. Protected feeds carry with -them social expectations: Twitter clients often either refuse to copy text -from a protected feed, or present a warning when the user tries to copy text, -which acts as a very cheap and, apparently, quite effective brake on the -casual re-sharing that Twitter encourages for public feeds.

-

DDOS As A Service

-

Gossamer's network protocol converges towards a total graph, where every node -knows how to connect to every other node, and new information (new posts) -rapidly push out to every single node.

-

If you've ever been privy to the Twitter “firehose” feed, you'll understand -why this is a drastic mistake. Even a moderately successful social network -sees on the order of millions of messages a day. Delivering all of this -directly to every node all of the time would rapidly drown users in -bandwidth charges and render their internet connections completely unusable.

-

Gossamer's design also has no concept of “quiet” periods: every fifteen to -thirty seconds, rain or shine, every node is supposed to wake up and exchange -data with some other node, regardless of how long it's been since either node -in the exchange has seen new data. This very effectively ensures that -Gossamer will continue to flood nodes with traffic at all times; the only way -to halt the flood is to shut off the Gossamer client.

-

Passive Nodes Matter

-

It's impractical to run an inbound data service on a mobile device. Mobile -devices are, by and large, not addressable or reachable by the internet at -large.

-

Mobile devices also provide a huge proportion of Twitter's content: the -ability to rapidly post photos, location tags, and short text while away from -desks, laptops, and formal internet connections is a huge boon for ad-hoc -social organization. You can invite someone to the pub from your phone, from -in front of the pub.

-

(This interacts ... poorly with the DDOS point, above.)

-

Traffic Analysis

-

When a user enters a new status update or sends a new private message, their -Gossamer node immediately forwards it to at least one other node to inject it -into the network. This makes unencrypted Gossamer relatively vulnerable to -traffic analysis for correlating Gossamer identities with human beings.

-

Someone at a network “pinch point” -- an ISP, or a coffee shop wifi router -- -can monitor Gossamer traffic entering and exiting nodes on their network and -easily identify which nodes originated which messages, and thus which nodes -have access to which identities. This seriously compromises the effectiveness -of Gossamer's decentralized, self-certifying identities.