mirror of
https://github.com/bits-wallet/specs.git
synced 2025-12-17 05:34:21 +01:00
3.9 KiB
3.9 KiB
Specs
BitsApp specifications (BAS in short) stand for BitsApp Implementation Specifications. Specs are written to provide open and accessible documentation for BitsApp implementation details.
- BAS-01: One-directional channels
- BAS-02: Expiring channel addresses
- BAS-03: Silent swaps
- BAS-04: Swap factories
- BAS-05: Swap initiation protocol
- BAS-06: Swap credit protocol
- BAS-07: Swap settlement protocol
- BAS-08: Swap statuses
- BAS-09: Payment statuses
- BAS-10: Interactive swap invoices
- BAS-11: Non-interactive swap invoices
- BAS-12: Permenant channel addresses
- BAS-13: Encumbered silent swaps
- BAS-14: Inbound swap settlement protocol
- BAS-15: Silent swaps trees
- BAS-16: Swap settlement credits
- BAS-17: Channel backups
- BAS-18: Channel recovery
- BAS-19: Swap service
- BAS-20: Routing service
- BAS-21: Service provider federation
Event Kinds
| kind | description | NIP |
|---|---|---|
| 0 | Metadata | 1, 5 |
| 1 | Text | 1 |
| 2 | Recommend Relay | 1 |
| 3 | Contacts | 2 |
| 4 | Encrypted Direct Messages | 4 |
| 5 | Event Deletion | 9 |
| 6 | Repost | 18 |
| 7 | Reaction | 25 |
| 40 | Channel Creation | 28 |
| 41 | Channel Metadata | 28 |
| 42 | Channel Message | 28 |
| 43 | Channel Hide Message | 28 |
| 44 | Channel Mute User | 28 |
| 45-49 | Public Chat Reserved | 28 |
| 10000-19999 | Replaceable Events Reserved | 16 |
| 20000-29999 | Ephemeral Events Reserved | 16 |
Message types
Client to Relay
| type | description | NIP |
|---|---|---|
| EVENT | used to publish events | 1 |
| REQ | used to request events and subscribe to new updates | 1 |
| CLOSE | used to stop previous subscriptions | 1 |
Relay to Client
| type | description | NIP |
|---|---|---|
| EVENT | used to send events requested to clients | 1 |
| NOTICE | used to send human-readable messages to clients | 1 |
| EOSE | used to notify clients all stored events have been sent | 15 |
| OK | used to notify clients if an EVENT was successuful | 20 |
Please update these lists when proposing NIPs introducing new event kinds.
When experimenting with kinds, keep in mind the classification introduced by NIP-16.
Criteria for acceptance of NIPs
- They should be implemented in at least two clients and one relay -- when applicable.
- They should make sense.
- They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
- There should be no more than one way of doing the same thing.
- Other rules will be made up when necessary.