You should rewrite it in Rust!

From 56631c1d5bc2ba08b0a51fc532b89812444494b4 Mon Sep 17 00:00:00 2001

From: DanConwayDev

Date: Fri, 1 Mar 2024 08:24:27 +0000

Subject: [PATCH] fix: filter out non-root patches in proposal lists

prevent non-root patches from displaying on homepage where possible

via client side filter for non-root patches on repositories

that support the latest nip34 spec

on repository pages this is included in the relay subscription but when

we are getting patches for all repositories, like on the homepage,

we don't know ahead of time which ones support the latest spec

---

src/lib/stores/Proposals.ts | 33 ++++++++++++++++++++++++++++++---

src/lib/stores/repos.ts | 15 +++++++++++++++

2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/src/lib/stores/Proposals.ts b/src/lib/stores/Proposals.ts

index e772d37..40f9bde 100644

--- a/src/lib/stores/Proposals.ts

+++ b/src/lib/stores/Proposals.ts

@@ -19,6 +19,7 @@ import {

} from '$lib/kinds'

import { extractPatchMessage } from '$lib/components/events/content/utils'

import { selectRepoFromCollection } from '$lib/components/repo/utils'

+import { returnRepoCollection } from './repos'

export const proposal_summaries: Writable = writable({

id: '',

@@ -106,7 +107,7 @@ export const ensureProposalSummaries = async (repo_id: string | undefined) => {

NDKRelaySet.fromRelayUrls(relays_to_use, ndk)

)

- sub.on('event', (event: NDKEvent) => {

+ sub.on('event', async (event: NDKEvent) => {

try {

if (

event.kind == patch_kind &&

@@ -117,6 +118,9 @@ export const ensureProposalSummaries = async (repo_id: string | undefined) => {

// link to proposal will not work as it requires an identifier

return

}

+ const repo_identifier =

+ extractRepoIdentiferFromProposalEvent(event) || repo_id || ''

+

proposal_summaries.update((proposals) => {

return {

...proposals,

@@ -125,8 +129,7 @@ export const ensureProposalSummaries = async (repo_id: string | undefined) => {

{

...summary_defaults,

id: event.id,

- repo_identifier:

- extractRepoIdentiferFromProposalEvent(event) || repo_id || '',

+ repo_identifier,

title: (

event.tagValue('name') ||

event.tagValue('description') ||

@@ -146,6 +149,30 @@ export const ensureProposalSummaries = async (repo_id: string | undefined) => {

],

}

})

+

+ // filter out non root proposals if repo event supports nip34+ features

+ if (!repo_id && repo_identifier.length > 0) {

+ const repo_collection = await returnRepoCollection(repo_identifier)

+ if (repo_collection.unique_commit) {

+ proposal_summaries.update((proposals) => {

+ return {

+ ...proposals,

+ summaries: [

+ ...proposals.summaries.filter(

+ (summary) =>

+ (event.tags.some(

+ (t) => t.length > 1 && t[1] === 'root'

+ ) &&

+ !event.tags.some(

+ (t) => t.length > 1 && t[1] === 'revision-root'

+ )) ||

+ event.id !== summary.id

+ ),

+ ],

+ }

+ })

+ }

+ }

}

authors_unsubscribers.push(

diff --git a/src/lib/stores/repos.ts b/src/lib/stores/repos.ts

index 2205bde..3c4d4cc 100644

--- a/src/lib/stores/repos.ts

+++ b/src/lib/stores/repos.ts

@@ -17,6 +17,21 @@ export const repos: {

[unique_commit_or_identifier: string]: Writable

} = {}

+export const returnRepoCollection = async (

+ unique_commit_or_identifier: string

+): Promise => {

+ return new Promise((r) => {

+ const unsubscriber = ensureRepoCollection(

+ unique_commit_or_identifier

+ ).subscribe((c) => {

+ if (!c.loading) {

+ unsubscriber()

+ r(c)

+ }

+ })

+ })

+}

+

export const ensureRepoCollection = (

unique_commit_or_identifier: string

): Writable => {

--

libgit2 1.7.1

Why do you say that?

It’s ok, to err is human, you probably will see the light at sole point

Use-case specific.

That's better as it allows easier filtering for everybody -- and if you want to display everything (for whatever reason) in your client just add a new kind to you REQs.

where is it specified?

We have that specified that way.

what kind should replies to non-kind-1 events be?

1) kind 1

2) non-broadcast generic reply kind

3) use case specific kind

what kind should replies to non-kind-1 events be?

1) kind 1

2) non-broadcast generic reply kind

3) use case specific kind

Yes.

Interesting. It never occurred to me that you wouldnt just restore the latest version that was on record and rebuild from there.

Is it because you didn't realise it was lost until you added some more people?

It is not good for recovering lost follows because it only offers a way to restore a previous follow list, not to grab people back from that.