{"action":"created","issue":{"url":"https://api.github.com/repos/ipfs/specs/issues/225","repository_url":"https://api.github.com/repos/ipfs/specs","labels_url":"https://api.github.com/repos/ipfs/specs/issues/225/labels{/name}","comments_url":"https://api.github.com/repos/ipfs/specs/issues/225/comments","events_url":"https://api.github.com/repos/ipfs/specs/issues/225/events","html_url":"https://github.com/ipfs/specs/issues/225","id":517335380,"node_id":"MDU6SXNzdWU1MTczMzUzODA=","number":225,"title":"RPC over REST","user":{"login":"Stebalien","id":310393,"node_id":"MDQ6VXNlcjMxMDM5Mw==","avatar_url":"https://avatars2.githubusercontent.com/u/310393?v=4","gravatar_id":"","url":"https://api.github.com/users/Stebalien","html_url":"https://github.com/Stebalien","followers_url":"https://api.github.com/users/Stebalien/followers","following_url":"https://api.github.com/users/Stebalien/following{/other_user}","gists_url":"https://api.github.com/users/Stebalien/gists{/gist_id}","starred_url":"https://api.github.com/users/Stebalien/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Stebalien/subscriptions","organizations_url":"https://api.github.com/users/Stebalien/orgs","repos_url":"https://api.github.com/users/Stebalien/repos","events_url":"https://api.github.com/users/Stebalien/events{/privacy}","received_events_url":"https://api.github.com/users/Stebalien/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2019-11-04T18:49:34Z","updated_at":"2019-11-05T01:09:57Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"Re: https://github.com/ipfs/specs/pull/224\r\n\r\nI'd like to move in the _opposite_ direction: switch to a transport-agnostic RPC API internally so we can support multiple RPC protocols/libraries and multiple transports. I'm concerned that REST, specifically the use of verbs like PUT, DELETE, etc.) will tightly couple us to HTTP.\r\n\r\nWhy:\r\n\r\n1. Eventually, I'd like to support efficient memory sharing RPC systems using unix domain sockets, memory maps, and file descriptor passing.\r\n2. I'd like to avoid re-implementing bindings for every command when we do this.\r\n3. I'd like multiplex multiple commands over a single connection. HTTP/2 can do this but it requires TLS which requires a CA cert.\r\n4. Progress reported by `ipfs get` and `ipfs cat` is currently incorrect because we can't accurately calculate the size of the response before we send it. To fix this, we'll likely need to send _chunks_ of data along with progress information. However, that will break `curl -o file .../api/v0/get/ipfs/QmFoo`.\r\n5. I'd like to drop everything related to multipart.\r\n\r\n---\r\n\r\nThoughts? What about JSON RPC (or some similar protocol, ideally using CBOR)?"},"comment":{"url":"https://api.github.com/repos/ipfs/specs/issues/comments/549618409","html_url":"https://github.com/ipfs/specs/issues/225#issuecomment-549618409","issue_url":"https://api.github.com/repos/ipfs/specs/issues/225","id":549618409,"node_id":"MDEyOklzc3VlQ29tbWVudDU0OTYxODQwOQ==","user":{"login":"warpfork","id":627638,"node_id":"MDQ6VXNlcjYyNzYzOA==","avatar_url":"https://avatars2.githubusercontent.com/u/627638?v=4","gravatar_id":"","url":"https://api.github.com/users/warpfork","html_url":"https://github.com/warpfork","followers_url":"https://api.github.com/users/warpfork/followers","following_url":"https://api.github.com/users/warpfork/following{/other_user}","gists_url":"https://api.github.com/users/warpfork/gists{/gist_id}","starred_url":"https://api.github.com/users/warpfork/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/warpfork/subscriptions","organizations_url":"https://api.github.com/users/warpfork/orgs","repos_url":"https://api.github.com/users/warpfork/repos","events_url":"https://api.github.com/users/warpfork/events{/privacy}","received_events_url":"https://api.github.com/users/warpfork/received_events","type":"User","site_admin":false},"created_at":"2019-11-05T01:09:57Z","updated_at":"2019-11-05T01:09:57Z","author_association":"MEMBER","body":"FWIW, I don't think it would be at all out of line to think about specing some sort of RPC-ish system that's codec agnostic and under either the umbrella of either IPLD or libp2p.\r\n\r\nPretty much all the other options out there seem to be tightly bound to a specific single codec, and that strikes me as... unfortunate.\r\n\r\nWe've already done some protocols that are defacto doing this -- e.g. Graphsync, which is doing something RPC-like (without having an explicit RPC library) over IPLD and incidentally using CBOR.  It seems to work fine."}}
{"actor":{"display_login":"warpfork"}}