Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIP-34!: use NIP-22 thread style for patch and status events #1799

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

DanConwayDev
Copy link
Contributor

I created this as part of reviewing #1744. I don't think its worth merging these changes because the are breaking but I thought I'd share them anyway.

For the status event, references to merged patch events are done using the q tag even though the they are not included in content. This is because NIP-22 only supports the use of e reference for the parent event id.

vitorpamplona and others added 5 commits February 5, 2025 11:11
deprecate NIP-10 style threading and replace with NIP-22 style for
additional patches in patch set and patch revision roots.

improve tag clarity for patch revisions

omit repo ann tag for additional patches in set to enable filters
that just include root and revision root patches.

BREAKING CHANGE: NIP-34: replace NIP-10 style threading with NIP-22
for patch events
deprecate NIP-10 style threading and replace with NIP-22 style for
additional status.

merged patch event are referenced using the `q` tag even though the
they are not included in `content`. this is because NIP-22 only
supports the use of `e` reference for the parent event id.

I (DanConwayDev) don't think this is worth making this change as it
is breaking.

BREAKING CHANGE: NIP-34: replace NIP-10 style threading with NIP-22
for status events
@vitorpamplona
Copy link
Collaborator

Nice! Looks great to me!

@vitorpamplona
Copy link
Collaborator

Actually, I wonder if we should create a Patch Root kind and Patch Revision kinds. That's closer to how NIP-22 works (separate kinds for root and reply/revision) and avoids having to add t root to mark root elements.

Are patch revisions threads with multiple branches or just one branch? Does a revision include all the changes until that point or is the client supposed to apply the thread in sequence from root to leaf?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants