nostr-sdk / nostr-sdk-ios Goto Github PK

https://github.com/nostr-protocol/nips/blob/master/23.md

Once we have signing we can finish this up

Terry advised not yet ready on SDK.

The in-memory relay should be able to be loaded up with events and then connected to with existing classes.

It's a pain to have to type in a relay URL every time you run the app.

It would be useful to be able to tell which relay is which

https://github.com/nostr-protocol/nips/blob/master/30.md

It's possible that a Nostr event with malformed tags gets created. We should make the SDK resilient against this kind of data.

A proper tags subarray might look something like this:
["e", "hex-event-id"] or ["e", "hex-event-id", "other parameter"]

Examples of bad data that we should defend against:

• tags subarray is empty (i.e. [])
• tags subarray has only the tag name and no other value or parameters (e.g. ["e"])
• tags subarray has a tag name that is not a string (e.g. [["e"], "value"] or [1, "value"])
• tags subarray is not an array (e.g. "instead of an array, this is a string")

https://github.com/nostr-protocol/nips/blob/master/28.md

Add a simple URLSession request that validates NIP-05 identifiers.

https://github.com/nostr-protocol/nips/blob/master/05.md

NIP-08 is now deprecated in favor of NIP-27 (bech32 identifiers). Implement it for legacy compatibility for reading existing events only, not for creating new events.

https://github.com/nostr-protocol/nips/blob/master/08.md

nostr-protocol/nips#943

It was completely removed from NIP-01 on the master branch, and its only brief mention now is in the README. So we could even just delete the code rather than deprecating it. I don't think anybody has really ever used it.

2023-06-10 13:51:51.783271-0700 NostrSDKDemo[29109:47174192] [SwiftUI] Publishing changes from background threads is not allowed; make sure to publish values from the main thread (via operators like receive(on:)) on model updates.

https://github.com/nostr-protocol/nips/blob/ce7e6b2100918648ec4341c5fe517d076e8d225c/33.md

Many different kinds of Nostr events have overlap in how it is constructed, including semantic meaning of certain tags.

The current pattern of having one distinct creation function in the EventCreating protocol per kind makes it difficult to promote code sharing in the implementation.

For the developer who would be using Nostr SDK, it may be difficult to use the SDK to create events. It may make it harder for them to write maintainable or DRY (don't repeat yourself) code.

Let's explore if it's possible to use a builder pattern to solve these problems.

Examples might be for while the user is on another user's profile, or on a search results view.

https://github.com/nostr-protocol/nips/blob/master/36.md

https://github.com/nostr-protocol/nips/blob/master/52.md

https://github.com/nostr-protocol/nips/blob/master/09.md

When I use the SDK there are a lot of logs, it would be nice to be able to disable the SDK logs if the user wants

user story

As a nostr app dev who has strong preferences on app specific choices, I would love for nostr SDK to handle networking only, so that I can focus on app specific changes without having to worry about networking and compatibility with other clients & relays.

acceptance criteria

1. Nostr SDK implements best practice (e.g. outbox model) network connectivity to relays

performance requirements for Damus

@jb55 to provide

builds on

Add outbox to NDK #146

https://github.com/nostr-protocol/nips/blob/master/19.md

A lot of widespread have been made to the NIPs repo, including the merging of NIPs and introduction of new ones. Let's make sure our list in the README matches up with what's there.

I'm not sure if this is something that should be in the .gitignore or not..

https://github.com/nostr-protocol/nips/blob/b4cdc1a73d415c79c35655fa02f5e55cd1f2a60c/56.md?plain=1#L10

https://github.com/nostr-protocol/nips/blob/ce7e6b2100918648ec4341c5fe517d076e8d225c/09.md

I think we should have the word "request" in the type name, but open to discussion.

https://github.com/nostr-protocol/nips/blob/master/04.md

Message types

Client to Relay

Relay to Client

Progress

Client to Relay (RelayRequest)

• AUTH // Requires signing
• CLOSE #17
• COUNT#17
• EVENT #17
• REQ #17

Relay to Client (RelayResponse)

• AUTH #16
• COUNT #16
• EOSE #16
• EVENT #16
• NOTICE #16
• OK #16

Implement a way to validate signatures of incoming events. Maybe client applications can choose whether to validate incoming events or not.

The event creation logic is incorrect. It currently requires the root note to have an e tag with a root marker, which should not actually be required.

This one is big and may need to be done in pieces.

https://github.com/nostr-protocol/nips/blob/master/57.md

We need a way to create new Nostr events and sign them with a private key so that they can be sent to relays.

NIP-01 now defines several standard reply messages that relays can add to OK responses:
duplicate, pow, blocked, rate-limited, invalid, and error

Consume those and add them to RelayResponse so they will be available to clients.

https://github.com/nostr-protocol/nips/blob/master/01.md#from-relay-to-client-sending-events-and-notices

There's been a few instances of the demo app being broken due to breaking changes in the SDK.

Wss currently throws an error