Re: A Holistic Design Process for Developing a Prosocial Media Ecosystem

Adam Lake asked:

> 4. What are your concerns and/or disagreements with what you’ve read so
> far?

While I have a number of concerns, I would like to initially suggest that,
when defining a problem set, the problem definitions shouldn't assume or
require a particular solution or class of solutions. For example:

You list the following "issues" with the current state:

> 4. a. No guaranteed profile/data portability (relying on the decency of
> server hosts).
> 4. b. Sign-up confusion–which server should I choose and why?

If we assume that it is necessary for a user to select a specific server,
we could develop a wide variety of solutions to address the issues caused
by such choices. However, we would develop an entirely different set of
solutions if we did NOT assume that users must be bound to specific remote
servers. These issues exist only if it is necessary to select one of
potentially many remote servers to host profiles or posts. But, there are
approaches that wouldn't require such a choice. Given that, It may be that
these "issues" exist only because of previous design decisions. They may be
issues with existing systems and protocols while not being issues that are
inherent to the social media problem space. We should be careful to avoid
path-dependence and we should design systems that meet our needs, not
systems that merely fix bugs in previous designs.

We could, but should not, eliminate the "Sign-up" and "portability" issues
by simply having only a single, centralized service that serves all social
media. (i.e. Mega-Twitter or Mono-Meta) One to rule them all... Or, we
could re-envision things so that the Social Media protocols focused more on
providing infrastructural messaging support and focused less on
implementing the semantics of various applications. In such a system, more
would be demanded of the user's client and less of the remote service. For
instance, if we were to reorient to an architecture that assumed something
like WebSub at its core, rather than an "ActivityPub" server. The function
of the "Activity WebSub" server would be much like that of an email or
TCP/IP router, it would handle routing, fanout, etc. for posts as they flow
through the server, but wouldn't maintain inboxes, outboxes, or any other
data directly interrogated by users.

If we took inspiration from the IndieWeb POSSE
<https://indieweb.org/POSSE> advocates,
who say you should "Publish (on your) Own Site, Syndicate Elsewhere," we
might gravitate to a model that assumes that "servers" are either code
running on someone's own device(s), or as remotely-hosted single-user
services. Your "Outbox" might be replicated elsewhere, but it would live on
your own gear, not necessarily on some remote server. We could go a step
further and either store or replicate data on IPFS
<https://en.wikipedia.org/wiki/InterPlanetary_File_System> (The
InterPlanetary File Service), using content-based addressing, rather than
location-based addressing. (This would eliminate "HTTP-swarms" on
potentially under-powered personal servers.) Approaches such as these could
eliminate, or dramatically reduce, the significance of any "portability"
issues by making "location" irrelevant -- just as having only a single
server would eliminate these issues.

Today, we rely on servers for authentication and we must trust that "If
mastodon.social says 'Bob' or 'Alice' published something, we can believe
they did." This reliance forces a binding and dependency between users and
servers. But, if we were to adopt digital signatures or some of the
technologies being developed in the W3C Verifiable Credentials Working Group
<https://www.w3.org/groups/wg/vc/publications>, we would be able to make
non-refutable assumptions about a post's author, integrity, etc. without
depending on any particular "social media" service or instance. Given
signatures, included in published objects, we could determine an object's
author without even caring about the path taken by that object prior to our
evaluating it.

I am not trying to say that the issues you outlined aren't real. Certainly,
they are. New users constantly complain that they don't know how to choose
a server. But, instead of making it easier to choose, we might do better by
eliminating the need for the choice. (The easiest decision to make is one
that need not be made.) I am only suggesting that we should be careful not
to approach this problem as one of bug-fixing existing implementations.
We've learned a lot about how distributed systems work and can work since
we first started talking about ActivityStreams, etc. Let's use what we've
learned.

bob wyman