From f3085812e9c160f63e0cb542378eb827112a54c2 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sat, 12 Jan 2019 23:51:49 +0000 Subject: [PATCH] more examples; remove widget MSC ref --- specification/proposals_intro.rst | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/specification/proposals_intro.rst b/specification/proposals_intro.rst index b7663e66..c8a2fd32 100644 --- a/specification/proposals_intro.rst +++ b/specification/proposals_intro.rst @@ -99,10 +99,8 @@ new version of the room algorithm. There is sometimes a dilemma over where to include higher level features: for instance, should video conferencing be formalised in the spec, or should it be -implemented via widgets (if one assumes that widgets have landed in the spec and -[MSC1236](https://github.com/matrix-org/matrix-doc/issues/1236) is merged)? -Should reputation systems be specified? Should search engine behaviour be -specified? +implemented via widgets? Should reputation systems be specified? Should search +engine behaviour be specified? There is no universal answer to this, but the following guidelines should be applied: @@ -135,11 +133,17 @@ registry) given that the spec's existing primitives of file transfer and extensible events (MSC1767) give excellent tools for transferring and visualising arbitrary rich data. +Supporting public search engines are likely to not require custom spec features +(other than possibly better bulk access APIs), given they can be implemented as +clients using the existing CS API. An exception could be API features required +by decentralised search infrastructure (avoiding centralisation of power by +a centralised search engine). + Conversely, features such as reactions, threaded messages, editable messages, -spam/abuse/content filtering, are all features which would clearly benefit the -whole Matrix ecosystem and require both client & server implementation -changes across the board to be implemented in an interoperable way, and so -necessitate a spec change. +spam/abuse/content filtering (and reputation systems), are all features which +would clearly benefit the whole Matrix ecosystem and require both client & +server implementation changes across the board to be implemented in an +interoperable way, and so necessitate a spec change. Process -------