Skip to content
This repository has been archived by the owner on Jun 17, 2020. It is now read-only.

RChain Architecture document revision #580

Open
dckc opened this issue Apr 5, 2018 · 25 comments
Open

RChain Architecture document revision #580

dckc opened this issue Apr 5, 2018 · 25 comments
Assignees
Labels
developer-education guide: @JoshyOrndorff cf. #692 Sep 29 needs-SMART-objective Specific; Measurable; Assignable; Realistic; Time-related

Comments

@dckc
Copy link
Contributor

dckc commented Apr 5, 2018

A few people, including one of the authors (@edeykholt), have noticed that the architecture document is out of date in a few places (e.g. SpecialK). Meanwhile, several groups have translated it into various languages, so they must know it pretty well. I have talked with @MParlikar about organizing an effort to update the document, and she supports the idea and says it's worth some of Mike Stay's time.

Let me know if you're interested and available to

  • raise issues in the arch doc repository
  • meet occasionally to discuss them
  • make pull requests to fix them
  • update your translation

Candidates:

cc @Jake-Gillberg

@ghost
Copy link

ghost commented Apr 5, 2018

@dckc ok

@qelentium
Copy link

@dckc im in! :)

@dckc
Copy link
Contributor Author

dckc commented Apr 6, 2018

My RChain office hours might be a good time to talk about this. Saturdays 9am Chicago time. See #403 for details.

@dckc
Copy link
Contributor Author

dckc commented Apr 7, 2018

@AbnerZheng and I talked about this today.

I don't have rights to merge PRs, but that's OK, at least for now; we want changes to go through @pyrocto anyway.

For typos and obvious fixes, just file pull requests like #21.

For parts that we suspect are out of date but we're not sure how it should be updated, file issues like SpecialK out of date? #23. @pyrocto confirmed that he sees such issues.

@staff91 @qelentium we're not planning any regular meetings yet, but do look for an opportunity to talk with me on discord / zoom / hangouts / phone.

@rolandkofler
Copy link

Is rabbitmq still part of the new architecture?

@rolandkofler
Copy link

@dckc what is the purpose of translations? Technical audience generally must be able to read English documentation. With a few exceptions like programmers in China maybe. Is the target audience broader?

@dckc
Copy link
Contributor Author

dckc commented Apr 24, 2018

The purpose that interests me is that people who translated the architecture document know it well as a result.

@TrenchFloat TrenchFloat added Development splitting into core-dev, developer-education, ...? (guides: @dckc, ...) zz-Translation NEEDS SPONSOR labels May 2, 2018
@dckc
Copy link
Contributor Author

dckc commented May 18, 2018

rchain/mobile-process-calculi-for-blockchain#3 is still pending, since January.

@dckc dckc added the needs-SMART-objective Specific; Measurable; Assignable; Realistic; Time-related label May 24, 2018
@dckc
Copy link
Contributor Author

dckc commented Jun 30, 2018

The diagrams and such from the RChain VM talk by @leithaus and co in Boulder are really good. I hope to integrate them into an arch doc revision.

@dckc
Copy link
Contributor Author

dckc commented Jun 30, 2018

I made some review progress June 18; I used an rchain-archdoc discord server to take notes as I read along, and filed important stuff in the https://github.com/rchain/architecture-docs/ repo

@dckc dckc added zz-RChain Technical Literacy see developer-education and removed Development splitting into core-dev, developer-education, ...? (guides: @dckc, ...) labels Aug 1, 2018
@AyAyRon-P
Copy link
Contributor

Hi @dckc is there any update for this issue or can we close this out and use it as a point of reference?

cc @pavlos1851

@dckc
Copy link
Contributor Author

dckc commented Aug 4, 2018

I still plan to work on it.

It's only tangentially related to Translation though...

@dckc dckc assigned JoshOrndorff and TrenchFloat and unassigned AbnerZheng and qelentium Oct 18, 2018
@dckc
Copy link
Contributor Author

dckc commented Oct 18, 2018

@JoshOrndorff hopes to take a look at a chapter or so and sync with me next Thu.

I brainstormed a little with @TrenchFloat about some options too. I'll let him share.

@dckc dckc added developer-education guide: @JoshyOrndorff cf. #692 Sep 29 needs-SMART-objective Specific; Measurable; Assignable; Realistic; Time-related and removed needs-SMART-objective Specific; Measurable; Assignable; Realistic; Time-related zz-RChain Technical Literacy see developer-education labels Oct 18, 2018
@JoshOrndorff
Copy link

I've forked the repo to https://github.com/rchain-community/architecture-docs so we can collaborate and merge each others PRs without the lag time in the main rchain repo. Couple of big picture questions. @dckc @plantether

What should we do with stuff that is no longer in scope for the foreseeable like mobile process-friendly sharding? (I like 2)

  1. Remove all traces of it
  2. Mention that it still exists in old versions
  3. Leave it but note that it is out of scope

What should we do with stuff that is no longer in scope for Mercury, but is still possible for patch releases to Mercury? (I like 3)

  1. Remove all traces of it
  2. Mention that it still exists in old versions
  3. Leave it but note that it is out of scope for now

@edeykholt
Copy link

edeykholt commented Oct 24, 2018

I suggest 1 and 1, and just document the planned Mercury architecture. That way, the architecture document revision will get done sooner and help the project adoption. An architecture roadmap document can be started, initially as a draft, as a separate document. There could be a paragraphs in the Mercury architecture document that bullets out the roadmap concepts (but not release schedules) at a high level, the epic-epic ideas, including process-friendly sharding, a RhoVM closer to the metal, skSNARKS, additional encryption curves, plugable consensus algos, quantum resistant stuff, etc. Thank you for taking this on!!!

@dckc
Copy link
Contributor Author

dckc commented Oct 24, 2018

The Mercury design isn't much to write home about. The architecture can be aspirational; we don't have to get there right away. The architecture document is a recruiting tool; at least it was in my case.

In what way is mobile process-friendly sharding out of scope?

Once we have composite shards, though, we can use a single currency among those. -- @pyrocto Aug 25, 2018

@dckc
Copy link
Contributor Author

dckc commented Oct 24, 2018

I've forked the repo to https://github.com/rchain-community/architecture-docs so we can collaborate and merge each others PRs without the lag time in the main rchain repo.

Oh. Commits there won't go to http://arch-doc.rchain.coop/ via readthedocs. Oh... strange... http://arch-doc.rchain.coop/ gives a blank nginx page. But https://rchain-architecture.readthedocs.io/en/latest/ is still there. I'll have to see if I can change the github source that rtd uses.

@JoshOrndorff
Copy link

I'm leaning closer to @edeykholt on this one. Would be nice to Document what people can expect to use once mainnet launches. I like the idea of keeping a second document with the aspirational stuff, but I think the existing version of the archdoc pretty much does that, no?

regarding the repo choice, I was thinking that not immediately publishing to RTD was a feature. Would be nice to have proof readers before we publish.

@plantether
Copy link

I agree with Ed about version 1 so we can get it out and with @dckc for version 2.

@JoshOrndorff
Copy link

Yeah, now that I keep thinking about it I like the idea of writing up the full aspiration to get everyone excited about the stuff that me excited. Explain the full vision of what building on the RhoVM could be.

I guess a better way to ask the question is: If we're going to keep all of the aspirational stuff, are there actually significant revisions to be made? I'm sure typos stylistic stuff, a few minor corrects exist. Is that what we're after? Or maybe going through and flagging things as "already implemented" "mercury scope" "venus scope" "hopefully someday"?

@dckc
Copy link
Contributor Author

dckc commented Oct 26, 2018

regarding the repo choice, I was thinking that not immediately publishing to RTD was a feature.

That's what branches and such are for, no? Why shouldn't a merged PR affect the published version?

@dckc
Copy link
Contributor Author

dckc commented Oct 26, 2018

If we're going to keep all of the aspirational stuff, are there actually significant revisions to be made? I'm sure typos stylistic stuff, a few minor corrects exist. Is that what we're after?

Indeed, one approach is to treat it like a museum piece. The note on the cover page (rchain/architecture-docs#32) might be all we need for that. I have also filed a few PRs for typos.

Or maybe going through and flagging things as "already implemented" "mercury scope" "venus scope" "hopefully someday"?

Yes, another approach is to annotate sections with pointers to details on how it actually got implemented.

As to which future release something is going into, that involves an ongoing maintenance burden when schedules change, so I'd rather avoid that.

My preferred approach to parts that aren't implemented yet but we know they aren't right is to abstract away the incorrect details, leaving less info, but what remains is correct.

@JoshOrndorff
Copy link

@dckc submitted a PR that links to developer.rchain.coop for info about what is currently implemented. rchain/architecture-docs#32

I like that idea a lot, and I suggest that we re-brand this doc slightly as the "RChain architecture Vision" or something similar. Then we can keep in all the cool stuff about powerset sharding and mobile processes and whatnot and make revision a smaller task.

Point well taken about using branches. But I'd say the difficulty getting the existing PR merged is evidence enough that we should develop elsewhere in the meantime.

@JoshOrndorff
Copy link

Looks like no PRs have been merged in rchain/architecture-docs sice March https://github.com/rchain/architecture-docs/pulls?utf8=%E2%9C%93&q=is%3Apr

@dckc
Copy link
Contributor Author

dckc commented Oct 26, 2018 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
developer-education guide: @JoshyOrndorff cf. #692 Sep 29 needs-SMART-objective Specific; Measurable; Assignable; Realistic; Time-related
Projects
None yet
Development

No branches or pull requests

9 participants