From ab032cd29611a360eaf67251eebec9e7d952c5d9 Mon Sep 17 00:00:00 2001 From: mleku Date: Fri, 31 Jan 2025 02:20:48 -0106 Subject: [PATCH] switch to asciidoc and explain relay specialization --- doc/relays.adoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/relays.adoc b/doc/relays.adoc index 3a3d434..14dbae0 100644 --- a/doc/relays.adoc +++ b/doc/relays.adoc @@ -11,6 +11,8 @@ Instead of making a relay a hybrid event store and router, in REALY a relay does - a relay that stores and fetches media, including being able to convert and cache such as image size and formats - ...and many others are possible +By constraining the protocol interoperability compliance down to small simple sub-protocols the ability for clients to maintain currency with other clients and with relays is greatly simplified, without gatekeepers. + In addition, it should be normalized that relays can include clients that query other specialist relays, especially for such things as caching events. Thus one relay can be queried for a filter index, and the list of Event Ids returned can then be fetched from another relay that specialises in storing events and returning them on request by lists of Event Ids, and still other relays could store media files and be able to convert them on demand. For this reason, instead of a single centralised mechanism, aside from the basic specifications as you can see in link:./events_queries.adoc[REALY protocol event/query specification] it is possible to add more to this list without needing to negotiate to have this specification added to this repository, though once it comes into use it can be done. @@ -21,4 +23,4 @@ There need not be bureaucratic RFC style specifications, but instead use human-r Thus also it is recommended that implementations of any or all REALY servers and clients should keep a copy of the specification documents found in other implementations and converge them to each other as required when their repositories update support to changes and new sub-protocols. -Lastly, as part of making this ecosystem as heterogeneous and decentralized as possible, the notion of relay operators subscribing to other relay services such as media storage/conversion specialists or event archivists and focusing each relay service on simple, single purposes and protocols enables a more robust and failure resistant ecosystem where multiple providers can compete for clients and to be suppliers for other providers and replicate data and potentially enable specialisations like archival data access for providers that aggregate data from multiple other providers. \ No newline at end of file +Lastly, as part of making this ecosystem as heterogeneous and decentralized as possible, the notion of relay operators subscribing to other relay services such as media storage/conversion specialists or event archivists and focusing each relay service on simple, single purposes and protocols enables a more robust and failure resistant ecosystem where multiple providers can compete for clients and to be suppliers for other providers and replicate data and potentially enable specialisations like archival data access for providers that aggregate data from multiple other providers.