Network Working Group P. M. Hallam-Baker Internet-Draft ThresholdSecrets.com Intended status: Informational 14 October 2024 Expires: 17 April 2025 Mathematical Mesh 3.0 Part X: Everything draft-hallambaker-everything-02 Abstract https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 Hallam-Baker Expires 17 April 2025 [Page 1] Internet-Draft Everything October 2024 1.1. Content Format . . . . . . . . . . . . . . . . . . . . . 4 1.2. Everything Notification Message . . . . . . . . . . . . . 5 1.3. Protocols and Services. . . . . . . . . . . . . . . . . . 5 1.4. Mesh Account Addresses and Mesh Callsigns . . . . . . . . 6 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Related Specifications . . . . . . . . . . . . . . . . . 7 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 8 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 8 3. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Security Model . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Confidentiality and Integrity . . . . . . . . . . . . 8 3.1.2. Abuse Control . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Traffic Analysis Resistance . . . . . . . . . . . . . 9 3.2. Asynchronous Messaging and Mail . . . . . . . . . . . . . 10 3.3. Asynchronous Collaboration . . . . . . . . . . . . . . . 11 3.4. Asynchronous Social Media . . . . . . . . . . . . . . . . 12 3.4.1. Author Role . . . . . . . . . . . . . . . . . . . . . 12 3.4.2. Reader Role . . . . . . . . . . . . . . . . . . . . . 13 3.4.3. Publisher Service . . . . . . . . . . . . . . . . . . 13 3.4.4. Curation Service . . . . . . . . . . . . . . . . . . 14 3.4.5. Aggregation Service . . . . . . . . . . . . . . . . . 14 3.5. Synchronous Messaging . . . . . . . . . . . . . . . . . . 14 3.6. Synchronous Voice and Video . . . . . . . . . . . . . . . 15 3.7. Conferencing . . . . . . . . . . . . . . . . . . . . . . 15 4. ETML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Level 3 . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. Inline SVG . . . . . . . . . . . . . . . . . . . . . . . 21 5. Everything Notification Message . . . . . . . . . . . . . . . 21 5.1. Shared Classes . . . . . . . . . . . . . . . . . . . . . 21 5.1.1. Structure: Header . . . . . . . . . . . . . . . . . . 21 5.1.2. Structure: TextInput . . . . . . . . . . . . . . . . 22 5.1.3. Structure: Footer . . . . . . . . . . . . . . . . . . 23 5.1.4. Structure: Item . . . . . . . . . . . . . . . . . . . 23 5.1.5. Structure: Feedback . . . . . . . . . . . . . . . . . 23 5.1.6. Structure: Comment . . . . . . . . . . . . . . . . . 23 5.1.7. Structure: Publication . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 24 6.1.1. Traffic Analysis . . . . . . . . . . . . . . . . . . 24 6.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.1. Bullying . . . . . . . . . . . . . . . . . . . . . . 24 6.2.2. Sybil attack (brigading). . . . . . . . . . . . . . . 24 6.3. Service . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.1. Censorship . . . . . . . . . . . . . . . . . . . . . 24 6.3.2. Data Loss . . . . . . . . . . . . . . . . . . . . . . 24 Hallam-Baker Expires 17 April 2025 [Page 2] Internet-Draft Everything October 2024 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. Appendix A: ETML Schema . . . . . . . . . . . . . . . . . . . 25 10. Normative References . . . . . . . . . . . . . . . . . . . . 25 11. Informative References . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Everything is a document format, notification structure and protocols that provide a consistent and coherent infrastructure for human interaction through the Internet. All existing modalities of human Interaction addressed by existing Internet protocols are supported, these include: * Mail * News and mailing lists * Chat * Voice and Video * Conferencing * Collaboration Despite the wide scope of Everything's capabilities, the adoption of a consistent approach to all forms of messaging with end-to-end security built in allows a considerable reduction in client complexity. Everything builds on existing approaches. Where possible, existing protocols and infrastructure are adopted without modification (e.g. use of WebRTC for voice and video interaction). In other cases, existing formats are adapted. Everything is an Open Infrastructure in which there are no gatekeepers determining who is allowed to provide service, any user may use the service provider of their choice and change their choice of service provider without switching costs. Hallam-Baker Expires 17 April 2025 [Page 3] Internet-Draft Everything October 2024 1.1. Content Format Everything Text Markup Language (ETML) is an XML markup built on a subset of HTML that is purely focused on the expression of content. Presentation capabilities such as choice of fonts, size, color etc. are intentionally omitted. Specifying a separate markup language for Everything messaging permits HTML features that are undesirable or present security risks to be omitted. ETML does not support presentation capabilities such as choice of fonts, size, color etc. ETML documents MUST NOT include any form of scripting or active code capability. ETML is divided into three tiers, each of which of represent the content capabilities commonly used in a set of existing interactions: Paragraph

Basic text formatting of single paragraphs of text with emphasis (italic, bold, underline, etc.) with links to remote content and included images and video. Typical uses include chat messages, comments and annotations on documents. Post Structured texts with titles, subtitles and section headings. Typical uses include mail messages and blog posts. Document Richer structured texts with captioned images etc. Intended for use in longer articles and papers. Advanced notations such as markup for mathematics, chemistry, physics, chess, etc. are supported through use of an extension schema (e.g. MathML for mathematics) with alternative presentation in SVG being provided if the recipient does not have the ability to render the markup. Restricting user content to a limited repertoire according to context simplifies presentation of interactions in a comprehensible format. While texts such as Daniel Bomberg's 1519 edition of the Talmud demonstrate the practicality of presenting a base text, commentaries and commentaries on the commentary on a single page, attempting to present a book length commentary as response to a single paragraph of a base text is clearly absurd. Hallam-Baker Expires 17 April 2025 [Page 4] Internet-Draft Everything October 2024 Restricting user content also simplifies authoring and permits clients to act as gateways to legacy communications infrastructures (SMTP email, proprietary social media platforms). 1.2. Everything Notification Message Everything Notification Message (ENM) is a message format used to provide notification of content being available, In the case of very short text content, the notification may include the content itself. ENM messages consist of a DARE envelope containing a JSON body presenting the notification itself. This allows use of existing protocols used to synchronize DARE Sequences to be used to synchronize exchange of notifications. The ENM schema is based on the widely used RSS format to facilitate interoperability. The chief difference being that an RSS feed is an XML document which must be replaced every time an item is added while an ENM sequence is an append only log. Thus, while an RSS feed typically contains only the most recently updated items, an ENM sequence can contain the entire publication feed without performance penalty. 1.3. Protocols and Services. Support for the full range of interactions used in messaging, social media, mail etc. requires a wide range of services. As shown in section [TBS], support for social media interactions alone involves six separate roles and four different types of service. But even though the number of services is large the use of ENS messages encapsulated in DARE Sequences allows most of the interactions between these services to be implemented by a synchronization of DARE sequences. Support for the following services allows an Everything application to support the full range of functionality in both the authoring and receiving modes: Notification Publications Clients advise publishers of the availability of new content using the Mesh Service Post Mechanism. Content Publication Static content that is longer than the maximum payload of a Mesh Message is published using the HTTP POST method. Sequence Synchronization Deliver notification of the arrival of new content and feedback. Presence The Mesh Presence service is used to support synchronous Hallam-Baker Expires 17 April 2025 [Page 5] Internet-Draft Everything October 2024 messaging. Every device that is accepting inbound communication requests to a Mesh account maintains a constant connection to the corresponding presence service which acts as a broker and access control enforcement point for inbound communication requests. Voice and Video Streaming of audio and video content is provided by WebRTC under symmetric keys exchanged through the Mesh Presence service. The protocols supporting these services are either existing standards (e.g. WebRTC) or represent codification of existing practices that have evolved over decades within the consistent approach provided by the Mesh Architecture. 1.4. Mesh Account Addresses and Mesh Callsigns The internal identifier used to uniquely identify Mesh accounts is the UDF fingerprint of the root signature keys(s) of their Mesh profile. Since a string of 20 or more characters of Base-32 characters offers poor usability, provision is made to allow use of DNS account addresses and/or Mesh callsigns instead. A DNS Account Address is of the form defined in [RFC822] (_account_@_domain_) where _domain_ is the DNS address of the Mesh Service Provider servicing the account and _account_ is a text label uniquely identifies a particular Mesh account serviced by a provider. Mesh Clients MUST support use of internationalized domain names [RFC5890] and UTF8 Unicode addresses. A Mesh callsign is of the form @account as specified in [draft-hallambaker-mesh-callsign]. In normal circumstances, a callsign is a lifelong address that a once issued, a user can hold without payment of any renewal fee or other form of rent. The separation of the internal identifier from the human readable form allows users to make use of multiple account addresses and callsigns for the same account. The primary purpose of the human readable form is to facilitate contact exchange rather than to support addressing. For example, Alice initially registers her account with example.com which assigns her the address _alice@example.com_. She then registers the callsign @alice and @alice-lastname. Finally, Alice changes her service provider example.net which assigns her the account address alice68@example.net as the account 'alice' is already taken there. Hallam-Baker Expires 17 April 2025 [Page 6] Internet-Draft Everything October 2024 If Bob exchanges Mesh contact details with Alice, it is the contact entry in his address book used to send the message rather than alice@example.com, alice68@example.net, @alice, etc. Thus, he can enter any of these forms to send a message to Alice because the contact entry he has for Alice is bound to her permanent account fingerprint and is automatically updated when Alice changes her service provider. If Carol attempts to use the address alice@example.com after Alice has moved to example.net, the contact exchange will only succeed if example.com has not assigned Alice's account identifier to a new user and provides forwarding service to Alice's new account. 2. Definitions This section presents the related specifications and standards on which Everything is built, the terms that are used as terms of art within the Mesh protocols and applications and the terms used as requirements language. 2.1. Related Specifications Everything is built on the Mathematical Mesh platform and makes use of the data formats and service formats defined by the Mesh specification suite. The following specifications have particular relevance to Everything: Mesh Architecture [draft-hallambaker-mesh-architecture] Provides an overview of the Mesh architecture. Uniform Data Fingerprint [draft-hallambaker-mesh-udf] Describes the UDF format used to represent cryptographic nonces, keys and content digests in the Mesh and the use of Encrypted Authenticated Resource Locators (EARLs) and Strong Internet Names (SINs) that build on the UDF platform; Data at Rest Encryption [draft-hallambaker-mesh-dare]. Describes the cryptographic message and append-only sequence formats used in Mesh applications and the Mesh Service protocol. Reliable User Datagram [draft-hallambaker-mesh-rud]. Describes the Mesh presentation and transport layer. Mesh Callsign [draft-hallambaker-mesh-callsign] Describes issue and use of Mesh callsigns. Mesh Presence Service [draft-hallambaker-mesh-presence] Specifies the protocol used to establish synchronous interaction sessions. Hallam-Baker Expires 17 April 2025 [Page 7] Internet-Draft Everything October 2024 JSON-BCD Encoding [draft-hallambaker-jsonbcd]. Describes extensions to the JSON serialization format to allow direct encoding of binary data (JSON-B), compressed encoding (JSON-C) and extended binary data encoding (JSON-D). Each of these encodings is a superset of the previous one so that JSON-B is a superset of JSON, JSON-C is a superset of JSON-B and JSON-D is a superset of JSON-C. 2.2. Defined Terms This document makes use of the terms defined in [draft-hallambaker-mesh-architecture]. 2.3. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.4. Implementation Status The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer]. 3. Use Scenarios As its name suggests, Everything is designed to support the widest possible range of human interactions. But unlike the World Wide Web in which Web content is understood to be content that can be accessed using the vast majority of current Web browsers, it is not expected that every Everything client will support every form of interaction supported by Everything. The communication modalities supported by an application necessarily depends on the affordances offered by the device it is running on. While a user is very likely to perform collaborative editing of a document on a desktop or laptop, they are much less to be doing so on their smartwatch. 3.1. Security Model One of the chief advantages of deploying a new interaction infrastructure is the ability to apply a consistent security approach to every form of interaction. 3.1.1. Confidentiality and Integrity All user generated content is authenticated. All user generated content is end-to-end encrypted unless explicitly designated as public by the author. Hallam-Baker Expires 17 April 2025 [Page 8] Internet-Draft Everything October 2024 In cases where the set of authorized recipients is not known at the time content is generated or is subject to change, the content is encrypted under the key of a threshold encryption group and decryption of the content controlled by a Mesh key service. 3.1.2. Abuse Control Every interaction is gated by access control. Everything interactions are always brokered by one or more services. In the case of an asynchronous interaction, the broker is either the Mesh Service Provider of the recipient or a collaboration service host supporting a subset of the Mesh Service Protocol operations. In the case of a synchronous interaction, a Mesh Presence Service is used to establish a session. In each case, the inbound connection broker is responsible to perform access control on the communication request. Thus knowing the address or callsign of an Everything user does not in itself grant the ability to wake them at night and attempt to sell them double glazing. 3.1.3. Traffic Analysis Resistance Establishing a direct communication channel between the initiator and responder in a synchronous messaging or streaming interaction is most efficient but may compromise the privacy of the participants. IP addresses provide a powerful tracking tool that may expose the participants location or other identities. This concern may be efficiently addressed by introducing proxy forwarders. Since the RUD transport protocol ignores the packet source address, separate proxy forwarders may be used on the inbound and outbound connections. If a forwarder is trusted by both participants and third party traffic analysis is not being considered as a threat, a single stage of forwarding is sufficient. This approach is shown in Figure 1. (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 1: Concealing participant IP address. If third party traffic analysis is a concern or the forwarders are not trusted, a multi-level onion routing network may be established with different packets taking different routes through a network whose usage patterns are concealed by traffic from other parties and the use of flood fill approaches. This approach is shown in Figure 2. Hallam-Baker Expires 17 April 2025 [Page 9] Internet-Draft Everything October 2024 (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 2: Traffic analysis resistance via onion routing. 3.2. Asynchronous Messaging and Mail From a protocol point of view, asynchronous messaging services such as SMS only differ from email in the message sizes supported. Since SMTP is a push protocol in which the receiving mail server must accept and store the entire mail message on receipt, the message size is necessarily limited according to site policy. The maximum message size accepted is rarely more than a few MB and so larger data transfers are typically achieved by sending a link from which the receiver may retrieve the data from a clous service. Thus users are required to make use of three separate applications for very short messages, longer messages and very large data sets. In the Everything Mail model (Figure 3), a sender passes messages to a receiver through a four-corner model. If the message is small enough to fit inside a notification, the sender first forwards the message to their own service provider who forwards it to the service provider acting for the receiver from which the receiver may collect the message to read on their various devices. (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 3: Four Corner Mail. The outbound and inbound service providers perform access control on the notification request. The maximum notification message size is intentionally limited to a small value, currently 32KB. This has performance and implementation advantages. There is little point in synchronizing a streaming video file of several GB in length to the user's watch. Limiting notification message size allows an approach in which every Everything device downloads the complete notification spool. Transfer of longer messages is supported through a pull interaction in which the notification message contains only the message title and either an EARL providing the location of the encrypted resource and a decryption key in the case of a private message or a link to the resource in the case of a public message (Figure 4). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Hallam-Baker Expires 17 April 2025 [Page 10] Internet-Draft Everything October 2024 Figure 4: Mail With Large Payload. The notification-pull interaction removes the need to limit the size of messages transferred in the protocol, the only limit being the storage capacity available at the sender and receiver. This interaction is not currently fully specified. The following capabilities should be considered: * Specify the size and content type of the payload message * Provision for integration of anti-malware scanning services on content * Linking to 'live' documents that remain at the specified link * Caching of message content * Message recall Note that since a client MAY retrieve the message payload automatically without user interaction, message retrieval MUST NOT be considered proof of the message being read by a recipient. If a read receipt capability is required, this should be provided through a separate cryptographic enforcement mechanism such as Mikali fair contracts protocol. 3.3. Asynchronous Collaboration Asynchronous collaboration in closed communities presents a subset of the requirements of a global scale social network. For example, consider the case of a group of authors collaboratively editing a document through an annotation service. Authors read the document and associated annotations published by the Annotation Host and post their comments to the Annotation Host in response (Figure 5). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 5: Document Annotation Service. Comments made on a document MAY be tagged with a lightweight semantic as introduced by the [Open Meeting]. These tags provide context to tools designed to support document editors, highlighting parts of the document that need correction, clarification or further discussion. Hallam-Baker Expires 17 April 2025 [Page 11] Internet-Draft Everything October 2024 3.4. Asynchronous Social Media Asynchronous Social Media has rapidly established itself as one of the world's most popular forms of entertainment. But existing social media based on proprietary walled garden forums have received increasing criticism. In particular, the ability of the owner of the forum to control the agenda by selecting content users view and to suppress certain content entirely is not subject to any form of accountability towards the community established. Such circumstances are unlikely to endure. Enabling social media interaction at global scale is a challenging proposition even in the proprietary walled garden model. In an Open Infrastructure such as Everything, great care must be taken to ensure that the system scales both technically and socially. To achieve this scaling, it is useful to distinguish between the user in their content consuming role (Reader) and the user in their content creation role (Author). This in turn allows the functions of the social media platform to be broken down into a set of three distinct services (Publisher, Aggregator, Curator). This architecture is shown in Figure 6 in which the content (original posts and comments) flows downwards and reader feedback flows up. (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 6: Social Media Roles. 3.4.1. Author Role An Author is a participant that generates content either in the form of original content or comments. Each author chooses their content publisher and is free to change their decision at any time without switching costs. Authors can even set up their own Publication service. Thus, no author can be censored but neither is anyone forced to read the content they produce. Authors may publish content through more than one publisher. They may also publish content to legacy walled garden social media through a gateway provider (Figure 7). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Hallam-Baker Expires 17 April 2025 [Page 12] Internet-Draft Everything October 2024 Figure 7: Author Role. 3.4.2. Reader Role Readers select the content they consume, either directly from the publisher of individual author feeds or indirectly through a curation service which monitors multiple feeds selecting content likely to be of interest to their audience based on feedback notifications created by the reader (Figure 8). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 8: Reader Role. Feedback consists of lightweight semantic labels drawn from a constrained vocabulary defined by the recipient of the feedback notifications. To ensure interoperability, a core set of feedback semantics {Agree, Disagree, Like, Dislike} is defined. The inclusion of positive and negative feedback is based on the observation that systems that only allow positive feedback are inherently unstable. One objection commonly made to the 'reader choice' model is that the reader may not be the best judge of what content they consume. In particular, it is theorized that unless people are exposed to contrary viewpoints, they may adopt insular and uninformed viewpoints. The experience of a decade of social media based on such patronizing conceits is that the proprietors of such forums are most interested in promoting their own uninformed and parochial views. An environment in which the bully is able to force others to receive their ignorant views is quickly dominated by disinformation designed to suppress rational discourse. 3.4.3. Publisher Service A publisher receives content from one or more authors, publishes it to the corresponding feed and forwards the corresponding update notification messages to the readers, curators and aggregators subscribed to the feed (Figure 9). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 9: Publisher Service. The only requirement to offer a publication service is to have a suitable host that is always available and has a static public IP address. Hallam-Baker Expires 17 April 2025 [Page 13] Internet-Draft Everything October 2024 3.4.4. Curation Service One of the chief challenges in global scale social media is enabling readers to find content they find enjoyable or is useful to them. In the proprietary walled garden model, curators face a conflict of interest between presenting the content that will prove most profitable to them and the content their audience prefers. Experience has proved that it is na?ve to expect such conflicts to be resolved in favor of the user. In the Everything model, readers select the curation services they wish to use from a competitive marketplace in which curators compete to best serve the reader's interests. Curators are free to adopt the business models and the technologies of their choice (Figure 10). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 10: Curator Role. For most participants, social media is primarily an entertainment medium. We must accept that fact and give them the right to choose what content they consume. 3.4.5. Aggregation Service Aggregation Services act as brokers for notifications. Forwarding a notification to an aggregation service allows a publisher to avoid the need to track curators and vice versa (Figure 11). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 11: Aggregation Service. 3.5. Synchronous Messaging Establishing a synchronous text messaging interaction between two users presents a number of challenges: * The intended responder may not be available. * The intended responder may not wish to accept the interaction request * The intender responder may have multiple devices Hallam-Baker Expires 17 April 2025 [Page 14] Internet-Draft Everything October 2024 * The intender responder may behind a NAT device that does support inbound connection requests. These requirements are addressed through the use of a presence service. Whenever a device that is connected to a Mesh account is willing to accept inbound interaction requests, it maintains a constant connection to a presence service. To establish an interaction the initiator sends the request to the presence service servicing the account which performs an access control check on the request and if accepted, notifies the responder's connected devices. If the responder accepts the request, a bilateral communication channel is established between the initiator and the responder (Figure 12). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 12: Synchronous Chat. 3.6. Synchronous Voice and Video Establishing a synchronous voice or video interaction between two users presents essentially the same set of requirements as for text messaging but with the additional requirement of supporting streaming audio or video. Since the WebRTC protocols already provide this capability, it suffices to use the Mesh Presence service to establish the connection and perform the necessary key exchange (Figure 13). (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 13: Synchronous Voice and Video using WebRTC. One important limitation of this approach is that WebRTC is not designed to provide the same degree of traffic analysis resistance as the Mesh RUD transport. Another consequence of this design is that support for WebRTC capabilities on most platforms currently comes in the form of a captive Web Browser widget that is invoked by a parent application. While this approach offers all the power and rich functionality of Web technologies such as CSS and JavaScript, it also presents the accompanying attack surface. 3.7. Conferencing Conferences and meetings offer streaming content but are structured as an interaction in which participants interact with a central host (Figure 14). Hallam-Baker Expires 17 April 2025 [Page 15] Internet-Draft Everything October 2024 (Artwork only available as svg: see https://www.ietf.org/archive/id/draft-hallambaker-everything-02.html) Figure 14: Synchronous conference. While Everything is in principle capable of peer-to-peer meeting model, the social scaling challenges for structuring conversations of more than four people make use of such a scheme implausible. 4. ETML Everything Text Markup Language is a lightweight document markup designed for use in social media interactions. Unlike HTML 4.0 and later version which are primarily intended to provide presentation capabilities, ETML is focused on representing content and structure. One consequence of this more limited focus is that the ETML schema makes minimal use of attributes. id Element identifier, may occur in paragraph type elements Class Class identifier, may occur in paragraph type elements. The schema for ETML is shown in Section 9. 4.1. Level 1 ETML Level 1 is intended for representation of chat messages, comments and other short messages. There are two top level elements: *

Paragraph containing text data. * A sequence of paragraphs The

element may contain any of the following elements: Hallam-Baker Expires 17 April 2025 [Page 16] Internet-Draft Everything October 2024 +=========+===============+===================================+ | Element | Name | Description | +=========+===============+===================================+ | i | Italic | Italic text | +---------+---------------+-----------------------------------+ | b | Bold | Bold text | +---------+---------------+-----------------------------------+ | u | Underline | Underlined text | +---------+---------------+-----------------------------------+ | del | Deleted | Deleted text | +---------+---------------+-----------------------------------+ | ins | Inserted | Inserted text | +---------+---------------+-----------------------------------+ | tt | Fixed font | Fixed font | +---------+---------------+-----------------------------------+ | a | Anchor | Link to external resource | +---------+---------------+-----------------------------------+ | sub | Subscript | Subscript | +---------+---------------+-----------------------------------+ | sup | Superscript | Superscript | +---------+---------------+-----------------------------------+ | dfn | Definition | Mark surrounding paragraph as the | | | | definition of the term contained | +---------+---------------+-----------------------------------+ | img | Image | Image data | +---------+---------------+-----------------------------------+ | svg | SVG | Inline Scalable Vector Graphics | | | | markup (see TBS) | +---------+---------------+-----------------------------------+ | video | Video | Video data | +---------+---------------+-----------------------------------+ | bdi | Bidirectional | Bidirectional Isolation. | +---------+---------------+-----------------------------------+ | alt | Alternative | Contains a list of content blocks | | | | containing alternative | | | | descriptions of the same content. | +---------+---------------+-----------------------------------+ Table 1 [] 4.2. Level 2 ETML level 2 contains the elements of level 1 with the addition of structural elements to identify titles, headings, lists, etc. typically used in email messages, blog posts and other short articles. There is one top level element: Hallam-Baker Expires 17 April 2025 [Page 17] Internet-Draft Everything October 2024 Post Post containing structured text data. The additional tags specified in the level 2 repertoire mostly define specialized forms of paragraph style. +==========+==============+==================================+ | Element | Name | Description | +==========+==============+==================================+ | post | Post | Post containing structured text | | | | data. | +----------+--------------+----------------------------------+ | title | Title | Post title, a post may only have | | | | one title. On a mail message, | | | | the title is the subject. | +----------+--------------+----------------------------------+ | subtitle | Subtitle | Subtitle, a post may have | | | | multiple subtitles | +----------+--------------+----------------------------------+ | h1 | Heading 1 | First level heading | +----------+--------------+----------------------------------+ | h2 | Heading 2 | Second level heading | +----------+--------------+----------------------------------+ | h3 | Heading 3 | Third level heading | +----------+--------------+----------------------------------+ | h4 | Heading 4 | Fourth level heading | +----------+--------------+----------------------------------+ | dt | Tag | Defined tag | +----------+--------------+----------------------------------+ | dd | Data | Defined data | +----------+--------------+----------------------------------+ | li | Bullet | Bulleted list item | +----------+--------------+----------------------------------+ | ni | Numbered | Numbered item | +----------+--------------+----------------------------------+ | pre | Preformatted | Preformatted text used for | | | | examples, etc. | +----------+--------------+----------------------------------+ | quote | Quotation | Incorporate element from another | | | | post | +----------+--------------+----------------------------------+ | cite | Citation | Source citation. | +----------+--------------+----------------------------------+ Table 2 Tables are omitted from the Level 2 model on account of table editing capabilities presenting a considerable degree of complexity. Hallam-Baker Expires 17 April 2025 [Page 18] Internet-Draft Everything October 2024 4.3. Level 3 ETML Level 3 contains additional structural elements required in the production of articles, books and reports. There are two top level elements: document Contains a complete document fragment Contains a complete or partial document. The Level 3 markup adds features such as the ability to nest lists, add footnotes, endnotes, and captions and to mark document sections. Hallam-Baker Expires 17 April 2025 [Page 19] Internet-Draft Everything October 2024 +===========+===========+=========================================+ | Element | Name | Description | +===========+===========+=========================================+ | document | Document | Container for document elements. | +-----------+-----------+-----------------------------------------+ | fragment | Fragment | A document fragment which contains | | | | documents elements but is not | | | | necessarily a complete document. | +-----------+-----------+-----------------------------------------+ | cap | Caption | Captioned paragraph, image or video | | | | item | +-----------+-----------+-----------------------------------------+ | meta | Meta | Metadata describing the document. | +-----------+-----------+-----------------------------------------+ | tp | Tagged | Tagged paragraph belonging to a | | | | particular collection. | +-----------+-----------+-----------------------------------------+ | list | List | Container for list elements | +-----------+-----------+-----------------------------------------+ | foot | Footnote | Footnote presented in body of the text | +-----------+-----------+-----------------------------------------+ | end | Endnote | Endnote presented at the end of a | | | | document | +-----------+-----------+-----------------------------------------+ | section | Section | Section heading, used to divide longer | | | | document into sections | +-----------+-----------+-----------------------------------------+ | author | Author | Identifies an author | +-----------+-----------+-----------------------------------------+ | abstract | Abstract | Marks a set of paragraphs as an | | | | abstract | +-----------+-----------+-----------------------------------------+ | preamble | Preamble | Document preamble | +-----------+-----------+-----------------------------------------+ | main | Main | Marks the beginning of the main section | | | | of a document that begins with a | | | | foreword or abstract | +-----------+-----------+-----------------------------------------+ | postamble | Postamble | Marks the end of the main section of | | | | the document. Headings within the | | | | postamble will be marked as appendices. | +-----------+-----------+-----------------------------------------+ | table | Table | Table, as in HTML model | +-----------+-----------+-----------------------------------------+ Table 3 Hallam-Baker Expires 17 April 2025 [Page 20] Internet-Draft Everything October 2024 The ETML level 3 markup borrows heavily from the document markup specified in [RFC7991]. ETML documents may be converted to RFC7991 format and back again with little loss of information. The element may be used to specify a tagged paragraph. Tagged paragraphs may be used to mark a paragraph as a lemma or theorem. 4.4. Inline SVG ETML paragraphs and paragraph sequences MAY include an SVG element containing SVG content with the following restrictions: * The