I wonder if this is a bit too pinned (ha) to the stream metaphor.

The underlying problem seems to be that we're trying to represent a collection of persistent, evolving intellectual objects through an interface originally designed to display publication events.

Wikis solved a version of this problem decades ago by separating three things:

1. Activity: What changed recently? (Recent Changes, watchlists, notifications)
2. Landscape: What exists, and how is it organized? (Pages, indexes, categories, links)
3. History: How did this object develop? (Revisions, provenance, relationships)

These are three different questions that needn't be collapsed into one sorting function. A change to a Wikipedia article produces an event in Recent Changes; it doesn't move the article somewhere else in the encyclopedia.

I think Jyri Engeström's social object theory provides a useful broader perspective. Successful social software tends to organize around objects that people have independent reasons to interact with. GitHub is useful to a single developer pushing code to a repository. Flickr was useful simply for organizing photographs. The social features supercharge activities that already have value.

This suggests a useful progression for Blygger:

One author: A commonplace book, something like Roam, for developing an interconnected body of ideas over time. Fragments, revisions, links, transclusions, and collections are already useful without an audience.

Two authors: A correspondence. You develop ideas in conversation, incorporating and challenging each other's arguments. The correspondence itself becomes a persistent intellectual artifact.

Many authors: Something resembling the historical Republic of Letters, with ideas circulating, recombining, and developing across a decentralized network.

The basic test is whether Blygger is genuinely useful at the first stage. GitHub didn't have to invent a reason for people to interact with repositories; the repositories were already useful. The social network grew around the work.

This also makes me wonder whether we're looking for too much uniformity in the interface. Different activities naturally suggest different metaphors, both for authoring and consuming:

• Roam or a digital garden for accumulating and connecting fragments.
• GitHub repositories for larger composed works like essays, books, or research projects, with histories, forks, and releases.
• Wikis and libraries for navigating persistent bodies of knowledge.
• Feeds and inboxes for discovering activity and changes.
• Correspondence for following intellectual exchanges between authors.

Of course, supporting different views over the same underlying objects is already fundamental to Blygger's protocol design. That's precisely what makes exploring these different interfaces so interesting. We don't need to find one metaphor that does everything.

In particular, I'm not sure substantiality needs to determine where an object lives. A book doesn't become more prominent in a library every time someone revises it. Pins establish durable references, while revisions create events that might be interesting to subscribers. The object's persistent identity and its activity are separate concerns.

Perhaps the broader opportunity is to make evolving intellectual work into a first-class social object, rather than making a better feed of posts about intellectual work.

The feed is then one window onto that world, not the world itself. And the interesting design space is all the different ways authors and readers might inhabit that world.

Inertial feeds, feed pinning, pace-layered feeds

Just realized a basic problem. The authoring interface is both diachronic and synchronic, but the published surface is pure synchronic. We need a sort order that’s the diachronic equivalent of “reverse chronological” without being “algorithmic” (ie an order that’s not derived from semantics or subjective preferences). There are 3 variables available: number of versions, number of pins, depth of transclusions, possibly with versions and pins recursively accounted for. This gives an item a “weight” of “substantiality”. So the order is “descending weight” where weight = sum(pin-weighted version count*+discount*(sum(pin-weighted version count of all transcludes)).

Does this make sense?

This also solves the “book blyg” problem without need for a whole new client. You’d do this with a thread of threads that’s essentially a book where every chapter thread has gone through multiple versions, and many versions are pinned. This would score very heavy-weight in this scheme.

There aren’t that many parameters here so we could expose them in the settings as tuning knobs, and also have a checkbox for picking whether the default view should be reverse chronological or descending weight.

But the big idea: We can also think of blending by using the weight to determine how quickly the item flows down in the feed. The heavier it is, the stickier it gets. An item that’s been versioned 50 times and each is pinned will essentially be an immobile rock at the top of the feed, ie reproduce the “pinned items” behavior in trad feeds. Here there’s a slight issue. If the stream metaphor is generally understood as a top-down view, the weight-settling direction is into the stream. If it’s understood as front-on, like a waterfall, heavier weights should sink faster. I’m inclined to ignore this ambiguity since the “pin” metaphor already

Just realized: If you treat pins as depth you can just do pace-layering. And versions should basically be a “swim upstream one tick” event

from Venkatesh Rao's Blyg ↗ · snapshot of v2