This repository was archived by the owner on Jun 5, 2026. It is now read-only.
Chat Framework#81
Merged
Merged
Conversation
igor-sirotin
reviewed
Feb 6, 2026
igor-sirotin
left a comment
igor-sirotin
left a comment
Contributor
There was a problem hiding this comment.
Just dust for now, will leave actual comments next part.
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
osmaczko
approved these changes
Feb 7, 2026
igor-sirotin
approved these changes
Feb 10, 2026
igor-sirotin
left a comment
igor-sirotin
left a comment
Contributor
There was a problem hiding this comment.
Thanks! I'm happy with it as it is, but left some minor comments where I think it could be improved
|
|
||
| Chat protocols specifications can be long and dense documents. To fully describe a chat protocol there are many layers and operations which are required to be documented. This includes payloads, message transport, encryption as well as user level features such as account registration, typing indicators, content formatting. | ||
|
|
||
| With the vast amount of information required to maintain compatibility between applications - protocol documentation is either comprehensive which leads to large monolithic specifications or lacking the required details for interop between implementors. |
Contributor
There was a problem hiding this comment.
Either <...> or <...>. Which way are we choosing? 😄
The paragraph finishes here, but it sounds like our choice/solution is missing
Contributor
Author
There was a problem hiding this comment.
This is a great feedback point.
I was following the paradigm that "Background" describes the problem, "Theory" outlines the proposed solution. Clearly the Problem/Solution relationship is not clear.
I'll rework it in another PR
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
|
|
||
| ## References |
Contributor
There was a problem hiding this comment.
Suggested change
| ## References | |
| # References |
Comment on lines
+26
to
+37
| The chat protocol is decomposed into 3 distinct phases. | ||
|
|
||
| - **Discovery:** How does a Sender learn of other clients. | ||
| - **Initialization:** How does a Recipient learn a client wants to communicate with them. | ||
| - **Operation:** How do participants exchange content. | ||
|
|
||
| and transport details are divided into: | ||
|
|
||
| - **Delivery Service:** How are payloads routed and delivered to a client. | ||
| - **Framing Strategy:** How are payloads encoded. | ||
|
|
||
| Defining these 5 parameters allows for chat protocol implementations to be fully defined, which allows clients from different applications to exchange messages. |
Contributor
There was a problem hiding this comment.
What confuses me here is how we juggle with these terms to describe the same thing: components, phases, problem areas, parameters. I'm not sure how would I re-write this. I still get the content, it just feels a bit bumpy while reading.
Contributor
There was a problem hiding this comment.
specs/standards/application/chat-framework.md
Lines 64 to 69 in 21af11f
Here we say "phases of protocol lifecycle", this makes more sense to me than "phases of protocol".
Contributor
Author
There was a problem hiding this comment.
Absolutely. Let me think it over.
igor-sirotin
added a commit
to logos-co/logos-lips
that referenced
this pull request
Jun 2, 2026
…pecs Pristine copies of the last messaging specs not covered by #315/#331, imported as-is from logos-messaging/specs so the adaptation diff is isolated in the following commit: - chat-framework (logos-messaging/specs#81) - privatev1 (logos-messaging/specs#93) - introduction-encoding (logos-messaging/specs#101) - contentframe (logos-messaging/specs#82) - tor-push (Waku v2 Tor Push) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
igor-sirotin
added a commit
to logos-co/logos-lips
that referenced
this pull request
Jun 4, 2026
…pecs Pristine copies of the last messaging specs not covered by #315/#331, imported as-is from logos-messaging/specs so the adaptation diff is isolated in the following commit: - chat-framework (logos-messaging/specs#81) - privatev1 (logos-messaging/specs#93) - introduction-encoding (logos-messaging/specs#101) - contentframe (logos-messaging/specs#82) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
igor-sirotin
added a commit
to logos-co/logos-lips
that referenced
this pull request
Jun 4, 2026
Follow-up to #315 (and #331 for segmentation): moves the last messaging specs that still lived only in `logos-messaging/specs` into `docs/messaging/raw/`. YAML front matter is converted to the canonical `| Field | Value |` metadata table (`status: raw`); slugs and timelines are left to the build-time generators, matching #331. Split into two commits for review: the first imports each spec **verbatim** from `logos-messaging/specs`, the second isolates the logos-lips adaptations (metadata table + cross-reference rewrites). ## Specs moved | Spec | Source PR in logos-messaging/specs | | --- | --- | | `chat-framework.md` | [#81](logos-messaging/specs#81) Chat Framework | | `privatev1.md` | [#93](logos-messaging/specs#93) Chat Private | | `introduction-encoding.md` | [#101](logos-messaging/specs#101) Introduction encoding | | `contentframe.md` | [#82](logos-messaging/specs#82) Chat Content Frames — previously missed | ## Notes - `contentframe` had an empty `name:` in source; set to "Chat Content Frames" (per PR #82 title). - `introduction-encoding` had no `editor:`; populated from its `contributors:` list. - Cross-references to the old source repos (`waku-org/specs`, `vacp2p/rfc-index`) are rewritten to their new logos-lips locations using repo-relative links. - `standards/application/tor-push.md` is **not** moved: #315 already classified it as superseded by the existing `docs/anoncomms/raw/gossipsub-tor-push.md` (same protocol/editor, far more developed), so re-adding it would duplicate that spec. - `standards/core/enr.md` in the source repo is the Waku v2 ENR spec and already exists here as `docs/messaging/draft/31/enr.md`, so it was **not** moved. - The only remaining open PR in logos-messaging/specs is #57 (store-sync update), which targets an already-migrated spec and is out of scope. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces a specification which describes a modular framework for describing Chat protocols.
This provides context on where chat specifications fit in the larger picture, while providing a template for implementation specific specifications. The component model introduced is used to define the boundaries of the other chat protocols and describe how they integrate.