{"action":"created","issue":{"url":"https://api.github.com/repos/blockstack/blockstack/issues/376","repository_url":"https://api.github.com/repos/blockstack/blockstack","labels_url":"https://api.github.com/repos/blockstack/blockstack/issues/376/labels{/name}","comments_url":"https://api.github.com/repos/blockstack/blockstack/issues/376/comments","events_url":"https://api.github.com/repos/blockstack/blockstack/issues/376/events","html_url":"https://github.com/blockstack/blockstack/issues/376","id":280235346,"number":376,"title":"Near-Term Blockstack Architecture Planning","user":{"login":"kantai","id":1153552,"avatar_url":"https://avatars1.githubusercontent.com/u/1153552?v=4","gravatar_id":"","url":"https://api.github.com/users/kantai","html_url":"https://github.com/kantai","followers_url":"https://api.github.com/users/kantai/followers","following_url":"https://api.github.com/users/kantai/following{/other_user}","gists_url":"https://api.github.com/users/kantai/gists{/gist_id}","starred_url":"https://api.github.com/users/kantai/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kantai/subscriptions","organizations_url":"https://api.github.com/users/kantai/orgs","repos_url":"https://api.github.com/users/kantai/repos","events_url":"https://api.github.com/users/kantai/events{/privacy}","received_events_url":"https://api.github.com/users/kantai/received_events","type":"User","site_admin":false},"labels":[{"id":454362341,"url":"https://api.github.com/repos/blockstack/blockstack/labels/production","name":"production","color":"8BC34A","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2017-12-07T18:40:13Z","updated_at":"2017-12-07T22:20:53Z","closed_at":null,"author_association":"MEMBER","body":"Based on conversations online and offline with various team members at Blockstack and developers looking to build on Blockstack (and users of the Blockstack software), I spent some time trying to sketch out a near-term architecture of the various Blockstack components and their interactions, with an eye towards trying to (1) improve the stability of the software and APIs Blockstack provides and (2) reduce the complexity of dependencies between components. In my mind, each of these components would be a different \"project\" of Blockstack -- each component has a different version number, github repo, test cases, and build process (to the extent that unifying technologies can be used in multiple components, we should do that, but we should still be able to conceptualize the components as independent actors).\r\n\r\nI added a markdown file to this branch:\r\n\r\nhttps://github.com/blockstack/blockstack/blob/future-architecture/future-architecture.md\r\n\r\nAnyways, I'm going to tag the various stakeholders on the team for feedback and discussion @jcnelson @jackzampolin @larrysalibra @muneeb-ali @shea256  @yknl  -- I think we should discuss here and then try to merge changes and comments into the markdown file. \r\n"},"comment":{"url":"https://api.github.com/repos/blockstack/blockstack/issues/comments/350112356","html_url":"https://github.com/blockstack/blockstack/issues/376#issuecomment-350112356","issue_url":"https://api.github.com/repos/blockstack/blockstack/issues/376","id":350112356,"user":{"login":"kantai","id":1153552,"avatar_url":"https://avatars1.githubusercontent.com/u/1153552?v=4","gravatar_id":"","url":"https://api.github.com/users/kantai","html_url":"https://github.com/kantai","followers_url":"https://api.github.com/users/kantai/followers","following_url":"https://api.github.com/users/kantai/following{/other_user}","gists_url":"https://api.github.com/users/kantai/gists{/gist_id}","starred_url":"https://api.github.com/users/kantai/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kantai/subscriptions","organizations_url":"https://api.github.com/users/kantai/orgs","repos_url":"https://api.github.com/users/kantai/repos","events_url":"https://api.github.com/users/kantai/events{/privacy}","received_events_url":"https://api.github.com/users/kantai/received_events","type":"User","site_admin":false},"created_at":"2017-12-07T22:20:53Z","updated_at":"2017-12-07T22:20:53Z","author_association":"MEMBER","body":"> The way I look at blockstackd from an app/user/developer perspective is that blockstackd's main role is to give me a zone file when I give it a name. \r\n\r\nWhat about the historic operations for a name? Names owned by an address?\r\n\r\n> I propose we move the subdomain indexing functionality into blockstackd so that it can maintain the index of subdomains and return zone files for subdomains without having to use a separate component.\r\n\r\nYes, that's fine. If someone wants _custom_ subdomain resolution, they can always implement that separately.\r\n\r\n> Is it possible to combine Blockstackd, Blockstack API and the resolver? Would there be any reason for anyone to only install blockstackd and not want the resolver and API?\r\n\r\nI think this depends on  how much of the functionality of the resolver and api moves to the client. If we can move almost all of it to the client, then `blockstackd` is really simple. The idea behind separating them, is that if the api has support for complex queries (number of names in a namespace, number of names on a given blockchain, name history), the demand to change those queries will be high, and `blockstackd` should ideally be small and updated _very_ infrequently. "}}
{"actor":{"display_login":"kantai"}}