search

status-im / specs

Specifications for Status clients.
https://specs.status.im/
MIT License
14 stars 14 forks source link

Decide on SIP process and format #1

Open corpetty opened 5 years ago

corpetty commented 5 years ago

What do we want this repo to look like in terms of format of separate followed specs?

Are we to follow the given example of bittorrent? If so, then we need to come up with a process of BEP/EIP/BIP-like process.

I suggest we follow the following RFC2119 with regards to wording.

arnetheduck commented 5 years ago

EIP is based on https://www.python.org/dev/peps/ which I think is a good process to use when we grow up a bit since it's maybe a bit on the heavy side for where we are, right now. RFC2119 sgtm, and I'd start off with a normal PR workflow - this of course depends on there being a spec in an approachable format.

All this will become easier as well when we've migrated over to some machine-readable message specs as well (maybe we should invent one, if one doesn't exist - or piggyback on what's happening in ETH2-land with ssz/sos/etc).

oskarth commented 5 years ago

Started WIP here https://github.com/status-im/specs/pull/5, based on EIP and basic tweaks. If we want to start lighter we can do so, but it seems nice to at least have a template format, some basic types and standard headers.

RFC2119 is being used in current document protocol PR.

oskarth commented 5 years ago

Re wire format, created issue here https://github.com/status-im/bigbrother-specs/issues/10 Relevant for minimally viable data sync @decanus is working on

oskarth commented 4 years ago

Update: for now we are using a lightweight PR based workflow.

Post v1 this might change, but right now there's no strong need.

corpetty commented 4 years ago

leaving this here for later conversation: https://github.com/libp2p/specs#specs-framework

oskarth commented 4 years ago

For general organization: https://rfc.zeromq.org/