- From: Johannes Ernst <johannes.ernst@gmail.com>
- Date: Sun, 5 Mar 2023 21:05:02 -0800
- To: public-swicg@w3.org
- Cc: aaronngray@gmail.com, Benjamin Goering <ben@bengo.co>, Bob Wyman <bob@wyman.us>
- Message-Id: <132D2EE9-B4AA-41FC-9A60-A2E2867DBDC4@gmail.com>
The challenge is not so much on the “sender” side of things. Expressing and publishing more things than the standards defined is easily done, because everything here was done very nicely with extensibility in mind on so many levels. The challenge is on the “receiver” side of things. Because extensions are so easy on the “sender” side, “receivers" have no idea what to expect. Anybody can — and in practice, does — extend all sorts of things. But code has to be written for each possibility … which can only be enumerated by looking at what each potential “sender” implementation might possibly send, and that probably changes from version to version, too. And there is no explicit “base level” that everybody must support or a well-understood fallback mechanism. All this beautiful extensibility comes at a cost that’s mostly born by “receivers", and even just estimating what that cost is for a project is a research project in itself. As an implementor, I am very happy about the “sender” side of things. I am quite apprehensive on the “receiver” side. Compare to what Nostr is doing, for example. Bengo pointed to their spec earlier today in a different context: they start with base functionality [1] that 1) is good enough to support base-level social media as I understand it, and 2) everybody needs to support it. Everything additional is optional. This makes for very simple initial project: implement that doc, and you have features for your customer. I would like to nudge us to think in that direction. [1] https://github.com/nostr-protocol/nips/blob/master/01.md Best, Johannes Ernst Blog: https://reb00ted.org/ FediForum: https://fediforum.org/ Dazzle: https://dazzle.town/
Received on Monday, 6 March 2023 05:05:30 UTC