[ripe-list] The Future of Discussion Lists

[Please view this message as either plain text or HTML, according to 
your
  preference and the capabilities of the application you use to read 
mail]

On 29 May 2023, at 10:43, Anna Wilson wrote:

> When I attended my first RIPE in 1998, the idea that you could do 
> policy coordination on _the internet_, especially on an open list that 
> uncredentialled people could just join, was pretty radical.

Re "uncredentialled", see below ...

> It's not radical anymore. Well done, us.
>
> Leo's right, and the problems he identifies are real.

Yes, and Leo's not the only one.

> Reading this thread, most of what I see are "minimum requirements". 
> Implicit in this seems to be the idea that Important People Won't Join 
> if those requirements aren't met.
>
> What I don't see so much yet is a picture of what a new, radical, open 
> approach could look like. Which is the thing that made RIPE successful 
> in the first place.

I don't have that picture yet.  I can offer some brainstorming 
bullet-points
which I've assembled from

- things I (thought I) understood from Leo well before RIPE86,
- what I've seen while lurking in the hallway-chat channel of the RPKI 
Community Discord server,
- what I've noticed in this thread,
- various hallway conversations,
- some concerns of my own.

I hope these will help towards painting a clearer picture.

I'm sure I've inadvertently left some things, perhaps even important 
ones, out, and equally sure that one or other of you will help fill in 
the gaps.


## Disclaimer

No personal name used below, except that of the author, is intended
to refer to any actual person, living or dead.

## Preconceptions

Alternatively "prejudices", or "how things used to be".

- open standards (SMTP, MIME) ensured interoperability
- in-house service, not commodity at scale, and consequently:
   * local expert(s) with responsibility for operating server;
   * direct relationship between user and operator;
   * email address was quasi-credential; eg. Niall.oReilly at ucd.ie
     identified the sender because the local operator (probably Niall
	O'Reilly himself or a very close colleague) had to set up the mailbox;
   * direct resolution of almost all problems;
   * typically only two, or maybe three, parties involved: local
     server operator at ucd.ie, heanet.ie, and maybe list admin
	at ripe.net.

## Meanwhile

"It's email, Jim, but not as we (used to) know it."

- outsourced service, badge-engineered with domain-part of address;
- proprietary "enhancements" undermine interoperability;
- different aspects of service outsourced separately, perhaps 
indirectly:
   * mailbox hosting,
   * blocklists;
- indirect problem resolution via (chain of) outsourced providers;
- restricted range of problems which any given provider will address;
- message transmission may be restricted by a provider's policies;
- complexity due to richer set of standards (SPF, DKIM, SAML, OAuth, 
TLS).

## Use cases

- targeted/personal notification:
   * unique personal link to meeting platform,
   * access credential for e-voting system,
   * invoices, receipts;
- group communication:
   * informal or ephemeral chat;
   * on-the-record discussion;
   * formal announcement of milestone or other state transition, eg:
     - phase of discussion,
     - consensus,
     - beginning or end of term of office;

## Strengths of e-mail

- single client (MUA) gives user access to, and management of,
   many message feeds;
- variety of MUAs matching personal preference and workflow:
   * web-based,
   * editor-based,
   * dedicated application;
- list archives
   * support transparency,
   * provide backup for inadvertently deleted messages,
   * mitigate effect of non-delivery;
- mature technology (but see below).

## Weaknesses of e-mail

- mature technology (but see above);
- some (even many) people find alternative platforms better for
   informal, ephemeral, or more dynamic interaction;
- selective delivery, according to provider's policy.

## Challenges

- RIPE (and/or RIPE NCC) "branding";
- applicability of RIPE Code of Conduct to alternative means of
   communication;
- proprietary vs open-source platform;
- in-house or outsourced operation;
- selection of user application (UA):
   * risk of proliferation of UA applications,
   * aggregating UA apps (eg Mattermost);
- tapered (rather than abrupt) transition;
- parallel support for alternative delivery channels;


---

I hope this helps.

Niall


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ripe-list/attachments/20230601/e214654c/attachment.html>