#9 Reimplement filter by index

已合併
cesar 10 月之前 將 1 次代碼提交從 cesar/tag-indexing合併至 cesar/main

I was under the impression that only #p and #e were expected, but I was wrong. Per NIP-01, any single-letter tag is expected to be indexed.

As a convention, all single-letter (only english alphabet letters: a-z, A-Z)
key tags are expected to be indexed by relays, such that it is possible, for
example, to query or subscribe to events that reference the
event "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36" by
using the {"#e":
["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]} filter.

I was also wrong in implementing partial key matching in the indexes, removing a lot of code. I though this was cool for privacy reasons.

I was under the impression that only `#p` and `#e` were expected, but I was wrong. Per NIP-01, any single-letter tag is expected to be indexed. ``` As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key tags are expected to be indexed by relays, such that it is possible, for example, to query or subscribe to events that reference the event "5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36" by using the {"#e": ["5c83da77af1dec6d7289834998ad7aafbd9e2191396d75ec3cc27f5a77226f36"]} filter. ``` I was also wrong in implementing partial key matching in the indexes, removing a lot of code. I though this was cool for privacy reasons.
cesar10 月之前 關閉
該合併請求已經成功合併!
登入 才能加入這對話。
未選擇標籤
未選擇里程碑
未指派成員
1 參與者
正在加載...
取消
保存
尚未有任何內容