Re: What we might produce

On Mon, Dec 6, 2021 at 2:30 AM Mark Nottingham <mnot@mnot.net> wrote:

> The charter calls out two different kinds of activities that this group
> might pursue (each likely leading to a Report):
>
> 1) Where we proactively want to recommend* specifications or technologies
> as a remedy in a defined situation (e.g., social networking, chat, etc.),
> highlighting any gaps
> 2) Where we want to react to a such a proposal made elsewhere (e.g., when
> a competition regulator or other national body selects something)
>
> To kick off some discussion, here are my initial thoughts --
>
> The charter contains a few suggestions of initial areas we might explore
> for #1. I don't have any strong sense of where we should start, but it
> should probably be something smaller and more straightforward, so that we
> can get into a working cadence. E.g., taking on social networking to start
> with might be too much.
>
> When we make recommendations, I've been thinking we'd define things in
> terms of how they serve as a remedy to competition issues in specific,
> well-defined markets -- too often, people paint 'big tech' with very broad
> brushstrokes. However, that will require us to do some work, and also to
> predict (to a degree) how those markets might be characterised. So I'd be
> interested to hear what people think about how much we should relate our
> work to e.g., the various reports that have been produced recently.
>

Rather than predicting (which I agree is somewhat inevitable), I wonder if
this group could proactively discuss areas where we believe
interoperability could be useful to address consolidation. Sometimes those
will be technical areas that a regulator has already or will identify as
particular markets of concern and sometimes they might just be suggestions
that don't see any future policy mandates but even then this group's
reporting could be useful.

One form of output from this group might be, essentially, suggested
charters for areas of work. That is, we might do the scoping exercise that
is common in chartering a standards process -- noting user and market
needs; identifying technologies and standards that already exist; proposing
where work is and isn't likely to be useful; highlighting the deliverables
that are most important. Suggesting charter-style scopings might make it
clear that this community group isn't defining a set of standards itself or
blessing some existing standard as solving a problem. But scoped charters
could be useful guidance -- both to policymakers who want to understand
what kind of work would be necessary in different areas and to the industry
and technical community generally to see where interoperability could make
a big difference.

I also like the idea of picking some relatively manageable areas to start
with. One feature that I'm regularly reminded could be useful in
facilitating user switching is some "forwarding address" functionality;
that is, I don't want to be locked in to my account with a particular
service because I have connections there and it's impractical for me to
contact all of them individually and let them know about my new account
somewhere else. What's needed to be able to set up messages to forward
along so that they don't end up in a virtual dead letter office? What could
be used to help my subscribers automatically follow my move to a new
location? These questions came up in Mastodon development as a feature of
particular importance for federation: we need to facilitate user moves
between servers (not just the ability to have servers on different
accounts) in order to get the user empowerment of federation.

And an example of some area that is broad but may not be the most complex:
data portability requirements are relatively common, both in existing
regulations and in new proposals. Formats for downloading data and
uploading it somewhere else probably don't need to be complex as the APIs
to connect services directly, but without standards and interoperable
implementations, theoretical portability isn't likely to mean much in being
able to move away from a dominant service provider. It could be useful to
survey where standards do and don't exist for the data you can download
from an existing social or other service provider, and scope out the work
needed to make those portability transitions easier.

Looking forward to talking with you all soon,
Nick