[ripe-list] The Future of Discussion Lists
- Previous message (by thread): [ripe-list] The Chair Team Reports: Highlights from RIPE 86
- Next message (by thread): [ripe-list] The Future of Discussion Lists
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Niall O'Reilly
niall.oreilly at ucd.ie
Thu Jun 1 14:50:36 CEST 2023
[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: <https://lists.ripe.net/ripe/mail/archives/ripe-list/attachments/20230601/e214654c/attachment.html>
- Previous message (by thread): [ripe-list] The Chair Team Reports: Highlights from RIPE 86
- Next message (by thread): [ripe-list] The Future of Discussion Lists
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]