{"action":"opened","issue":{"url":"https://api.github.com/repos/KSP-CKAN/CKAN/issues/865","labels_url":"https://api.github.com/repos/KSP-CKAN/CKAN/issues/865/labels{/name}","comments_url":"https://api.github.com/repos/KSP-CKAN/CKAN/issues/865/comments","events_url":"https://api.github.com/repos/KSP-CKAN/CKAN/issues/865/events","html_url":"https://github.com/KSP-CKAN/CKAN/issues/865","id":77689398,"number":865,"title":"Proposal: Self-Published Metadata","user":{"login":"dbent","id":1547727,"avatar_url":"https://avatars.githubusercontent.com/u/1547727?v=3","gravatar_id":"","url":"https://api.github.com/users/dbent","html_url":"https://github.com/dbent","followers_url":"https://api.github.com/users/dbent/followers","following_url":"https://api.github.com/users/dbent/following{/other_user}","gists_url":"https://api.github.com/users/dbent/gists{/gist_id}","starred_url":"https://api.github.com/users/dbent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dbent/subscriptions","organizations_url":"https://api.github.com/users/dbent/orgs","repos_url":"https://api.github.com/users/dbent/repos","events_url":"https://api.github.com/users/dbent/events{/privacy}","received_events_url":"https://api.github.com/users/dbent/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-05-18T15:03:47Z","updated_at":"2015-05-18T15:03:47Z","closed_at":null,"body":"This is proposal is to allow mod authors to self-publish authoritative metadata for their mods by creating recursive `.netkan` files. The way I envisage it working is thusly:\r\n\r\nA `.netkan` file is created in the NetKAN metadata repository as follows:\r\n```json\r\n{\r\n    \"spec_version\": 1,\r\n    \"$kref\": \"#ckan/http/https://www.example.com/AwesomeMod.netkan\"\r\n}\r\n```\r\nThis `.netkan` is actually recursive, it simply references another `.netkan` file, except this one is published by the mod author.\r\n\r\nI've chosen to overload the HTTP `$kref` here, and indicate the recursive mode by having the URL end with `.netkan` as a matter of convention. If you want to be more explicit, a new `$kref` scheme could be used:\r\n\r\n```json\r\n{\r\n    \"spec_version\": 1,\r\n    \"$kref\": \"#ckan/netkan/https://www.example.com/netkan?mod=AwesomeMod\"\r\n}\r\n```\r\n\r\nIn either case, the NetKAN bot would download the `.netkan` periodically and use it exactly as if it were in the NetKAN metadata repository. Within their own `.netkan` file, Mod authors could choose to specify a Kerbal Stuff `$kref` or a GitHub `$kref`, or just use all explicit data.\r\n\r\nFor added flexibility the original `.netkan` (henceforth referred to as the \"MetaNetKAN\"), could append/override data in the Mod-authored `.netkan`. So for instance, if a mod author adds a `ksp_version_min` but fails to add a `ksp_version_max`, and subsequent updates cause the mod to break, a CKAN team member could change the MetaNetKAN to be:\r\n\r\n```json\r\n{\r\n    \"spec_version\": 1,\r\n    \"$kref\": \"#ckan/netkan/https://www.example.com/netkan?mod=AwesomeMod\",\r\n    \"ksp_version_max\": \"x.y.z\"\r\n}\r\n```\r\nAnd all is well.\r\n\r\nThe main benefits I see this having are twofold:\r\n\r\n1. Mod authors have more control and responsibility for their mods, which means more robust, accurate, and timely metadata. This also means mod authors can be more proactive about issues and less reliant on the CKAN team.\r\n2. CKAN team spends less time keeping on top of changes to upstream (a problem *a lot* of Linux distributions have)."}}