{"id":25830887,"url":"https://github.com/lab5e/config","last_synced_at":"2026-06-16T14:31:36.564Z","repository":{"id":57545757,"uuid":"299067885","full_name":"lab5e/config","owner":"lab5e","description":"Simple configuration transport protocol","archived":false,"fork":false,"pushed_at":"2020-09-27T22:53:38.000Z","size":18,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-02-28T22:38:50.830Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/lab5e.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-09-27T16:03:55.000Z","updated_at":"2020-09-28T04:06:46.000Z","dependencies_parsed_at":"2022-09-05T10:50:39.533Z","dependency_job_id":null,"html_url":"https://github.com/lab5e/config","commit_stats":null,"previous_names":[],"tags_count":3,"template":false,"template_full_name":null,"purl":"pkg:github/lab5e/config","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lab5e%2Fconfig","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lab5e%2Fconfig/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lab5e%2Fconfig/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lab5e%2Fconfig/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/lab5e","download_url":"https://codeload.github.com/lab5e/config/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lab5e%2Fconfig/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34410780,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-16T02:00:06.860Z","response_time":126,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-02-28T19:34:33.261Z","updated_at":"2026-06-16T14:31:36.548Z","avatar_url":"https://github.com/lab5e.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Config\n\nConfig is a transport protocol on top of protobuffer for defining\nextensible configuration protocols.  The protocol defines a request\nand a response structure.\n\nTo define a given configuration protocol for a device there needs to\nbe a defined set of commands and defined responses as part of the\napplication firmware and the backend services.  It is advisable to\ndocument this protocol in a place that can be referred to by all\ncomponents that depend on the given application protocol.\n\n## Build\n\nIn order to build this package you will need to have `protobuf`\ninstalled on your system.  If you do you also need `protoc-gen-go`\nwhich can be obtained by running\n\n    make deps\n\nIf you have both installed you can build and test with \n\n    make\n\t\nThis generates the protobuffer code and runs a simple test.  This is\nmeant to act as a tool for verifying changes to the protobuffer\ndefinition.\n\n**We intend to check in ready generated protobuffer code to this\nproject so that other projects can depend on these files without\nhaving to install the tooling to generate them**.\n\n## Documentation\n\n### Request and Response\n\nThe Request and Response messages are defined as follows:\n\n    message Request {\n        uint32 id = 1;\n        uint32 command = 2;\n        repeated Value values = 3;\n    }\n\n    message Response {\n        uint32 id = 1;\n        uint32 command = 2;\n        uint32 sequence = 3;\n        uint32 responseCode = 4;\n        repeated Value values = 5;\n    }\n\n\n#### `id` (Request, Response)\n\nThe `id` fields are used to correlate `Response` messages to their\n`Request` counterparts so that when a device responds to a request it\nwill copy the `id` from the `Request` into the `Response`.\n\nIf the `id` is 0 this means that the `Response` was in response to any\nparticular `Request`.\n\nA request can elicit multiple responses.  For instance if the response\ndoes not fit in a single message or if a request turns on logging and\nyou want to want to be able to correlate it to the `Request` that\nturned on logging.\n\n#### `command` (Request, Response)\n\nThe values of `command` are used to identify which command the\n`Request` represents.  This will be specific to each application.\n\n#### `values` (Request, Response)\n\nIn order to represent values that are sent with a `Request` or\nreturned by a `Response` we use the `Value` message which is just a\nstructure that can hold int32, int64, double, string or raw\nbytes.  \n\n    message Value {\n        uint32 id = 1;\n        int32  int32Val = 2;\n        int64  int64Val = 3;\n        double doubleVal = 4;\n        string stringVal = 5;\n        bytes bytesVal = 6;\n    }\n\n\nBoth `Request` and `Response` define the `values` field as\n`repeatable` which means you can have zero or more values in a given\n`Request` or `Response`.\n\nSince all fields are optional in proto3 it is up to the application to\ndefine which fields should be set for which commands.\n\n*We have avoided using `oneof` or similar tricks to maintain\nsimplicity.  We could save a few bytes of RAM and packet size, but at\nthe cost of added complexity*.\n\n#### `responseCode` (Response)\n\nThis field contains an application specific response code in the\n`Request` message.\n\n#### `sequence` (Response)\n\nThe sequence field is used to enumerate responses that require more\nthan one message.  It is recommended that the first response indicates\nhow many messages are expected if this is known.  For instance by\nadding a \n\nSequences should start with 0 (zero).\n\n\n## Recommendations\n\n### Document carefully\n\nAs mentioned above, it is recommended to document the application\nprotocols that make use of this transport in a common place so that\nboth the firmware and the backend software refers to the same\ndefinition of the protocol.\n\nYou should document all commands complete with which values will be\nset in both the request and response.  Make sure that for each\n`command` you document which `responseCode` values developers should\nexpect back.\n\n### Commands that should exist\n\nThere should at minimum be commands to ask the device for its current\nstatus (uptime, battery, id of any MCUs or peripherials attached,\nfirmware version etc) and commands to do simple household tasks like\nreboot the device etc.\n\n### Versioning\n\nBeware that this is a transport protocol and that the application\nprotocol you put on top of it should be versioned separately from the\ntransport protocol.\n\n## Ideas\n\n### Reserved commands\n\nIt might be a good idea to have some reserved commands that are\ndefined by default.  For instance commands to inquire for status,\nfirmware, serial numbers, ask the device to reboot etc.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flab5e%2Fconfig","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flab5e%2Fconfig","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flab5e%2Fconfig/lists"}