* Add NIP-95 - File Storage
* Add missing response info
* Make it clear that is is an HTTP file storage server integration
* Add monetization suggestion
* Use zap split tags for monetization suggestion
* Add resize option
* Add Zap Gates Integration
* Replace /nip96 convention with /.well-known/nostr.json configuration
* Relays can choose to also act as HTTP file storage server
* Remove nip96 tag in favor of x tags third element
* Fix typo
* Remove redirect cooperation
* Replaced 422 with 400 status code
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Update 96.md
Co-authored-by: Jon Staab <jstaab@protonmail.com>
* Make file expiration a range and add terms_of_service
* Add optional content_type field
* Add plans and tos
* Remove monetization
* Apply minor fixes
* Update 96.md
Co-authored-by: Semisol <45574030+Semisol@users.noreply.github.com>
* Fix after review
* Add kind 10096
* Apply suggestions
* Add suggestions
* Remove duplicate field
* Add optional is_nip98_required plan config
* Add suggestions
* Replace x with ox tag for original file hash
* Make minor changes
* Remove nip96 namespace response field
* Add note about alternative file processing flow
* Simplify processing flow
* Add nostrcheck to server list
* Add audio/* example
* Explain what metadata to show before processing is done
* Add nostrage to list
* Add eta
* Add sove to list and replace eta with percentage
* Fix status code
* Add nostr.build to list
* Add sovbit
* Add optional extra http servers to ox tag
* Add void.cat to list
* Small fix
* Remove ox third array element
---------
Co-authored-by: Jon Staab <jstaab@protonmail.com>
Co-authored-by: Semisol <45574030+Semisol@users.noreply.github.com>
As mentioned further down in NIP-01
> A REQ message may contain multiple filters.
The comma makes it more clear that the message array can container more than 3 items. So it is understood easily to match
```
// correct:
["REQ", <subscription_id>, filters1, filters2, …]
```
instead of
```
// wrong:
["REQ", <subscription_id>, [filters1, filters2, …]]
```
After discussing with Pablo, we decided to move away from relying on kind 1063 events and instead use the majority of the same tags for video events. The main motivations behind this are to allow for parameterized replaceable events for video events, prevent excessive `REQ` requests, not stringify event JSON in the `.content` section, ease of filtering by kind number, as well as some others. Happy to discuss this further.