1.0 #116
1.0 #116
Conversation
| In order to establish a signalling channel using SaltyRTC, the following | ||
| information has to be available to both peers: | ||
|
|
||
| * WebSocket URI scheme (`ws` or `wss`), |
There was a problem hiding this comment.
Ah: Although the SaltyRTC protocol takes many security measures to prevent eavesdropping, it is still highly RECOMMENDED to use WebSocket in its secure mode
There was a problem hiding this comment.
It's optional but recommended.
Protocol.md
Outdated
| ``` | ||
| <scheme>://<server-host>:<server-port>/<signalling-path> | ||
| ?<server-permanent-public-key>#<authentication-token-hex> | ||
| ``` |
There was a problem hiding this comment.
I'd format this by indentation, it's easier to read in ASCII form and the result is the same.
Readme.md
Outdated
| Note that the specifications' versions are independent from each other. | ||
| In case a new version of a specification breaks backwards compatibility | ||
| to another specification, it will include a section stating how | ||
| compatibility is affected. |
There was a problem hiding this comment.
Maybe we should also include a CHANGELOG.md file?
There was a problem hiding this comment.
I'd suggest adding a Changelog section into the specification once a specification is being updated. Having one log for several specs seems confusing to me. What do you think?
| Release Process | ||
| =============== | ||
|
|
||
| Signing key: https://lgrahl.de/pgp-key.txt |
There was a problem hiding this comment.
I'd recommend to include the fingerprint too.
Releasing.md
Outdated
| export VERSION=protocol|chunking-<version> | ||
| # For tasks: | ||
| export VERSION=task-<task-name>-<version> | ||
| export GPG=0482ABA6 |
There was a problem hiding this comment.
Could you specify the full fingerprint? https://evil32.com/
|
Ok now? |
Releasing.md(how can we both sign releases @dbrgn?)