Pull this repository into its own organization

[okdistribute]

Wireline will be adding external developers as part of our roadmap for the next three months. It would be ideal to have these developers play around with the core stack without necessarily having access to all of the other pieces of the code. It would also will make it easier to open source the libraries on their own as "lego-like" building blocks which will accomplish the following goals:

• make it easy for advanced distributed systems engineers in the space to contribute to API surface
• reduce bugs & feature creep by enforcing strict and small API surfaces per package
• difficult for competitors like Blockstack to take the code because they would need to hire someone who gets up to speed with lower-level semantics in the dat ecosystem, and we have relationships with all of those people
• build confidence in the external developers we add that these repositories will be open source and their work will be valued & seen by the outside community
• implicitly and immediately answers the question "What if Wireline WNS goes out of business?" because the low-level application code won't be tied to the Wireline name, and outside players are involved from the early days.

Let's create a GitHub organization that is still completely private and start moving SDK code there, as each their own separate repository with a clear API surface.

This should also include Apollo pieces (apollo-link-kappa).

We can then start adding outside developers (e.g., julian, noffle, sebastien?, rangermauve) to reduce noise for them and empower them to get started and start adding documentation.

I would like to have a planning meeting during Osaka to discuss some ideal code reorganization to make the whole thing a lot more "lego"-like, with @tinchoz49

[tinchoz49]

I agree, I would like to talk about this.

I think there are some modules that are already stable like and almost ready to be open source like: feed-store, from my perspective could be really beneficial for the community.

In the case of the modules like Protocol conceptually I really like the approach that Rich and Ash got I would like to follow those steps. But the implementation is really complicate, really hard to extend and debug too. I think we should start discussing how to find an elegant "lego"-like on those modules and during the process having the chance to update hypercore-protocol.

[richburdon]

+1. Martin can you say more about how you find Protocol to be difficult to use. Really want to understand your perspective here, because for me, this was a breakthrough in me personally being able to understand the entire stack. And with the small unit tests that make is very easy to create the different set of proto extensions. So, to me, this feels like Lego (tm), but tell me otherwise what that might look like.

[okdistribute]

We might want to consider using https://github.com/decentstack/ as the protocol layer. There's already a PR into multifeed to make this more robust kappa-db/multifeed#32. I talked to telamon and he is looking for collaborators on this stack if there are certain features wireline wants to add -- he aims to keep it really simple and extensible for multi-user applications. He is also open for consulting 2 days/week

Some more naming ideas for the GitHub organization:

• hyperwire
• wirebus
• threads
• peerbus
• cables
• megafeed // it's still a pretty alright name!

Then repositories:

• peerbus/protocol
• peerbus/feeds
• peerbus/framework
• peerbus/apollo-link
  ...etc

Ownership status for wireline team & geut. Collaborator status for external developers.

• Notice: all of the names I'm proposing are focused on the technology itself.

[okdistribute]

@elmasse @tinchoz49 what's the status on this? can we do this sooner rather than later so we can iterate on some of these core concepts? we could also copy the code to not breaking existing code, and then when the other one is ready, start feeding it back into mainline.

as far as naming, let's call it 'peerbus' for now and then we can change the name if we want later before we open source

[elmasse]

@richburdon should be who decides on the repository/organization names/move etc.

[okdistribute]

@elmasse thanks, @richburdon and I discussed this and came up with preliminary outline for the repository structure

WIRELINE Ecosystem

Contrast with react, ipfs, linux, ...

• github/dxos
  • protocol
  • gravity
  • echodb (?? TODO)
    • megafeed (??? TODO)
  • launchpad
  • framework
    • botkit
    • appkit
  • apps
    • docs
    • table -> echodb
    • chat -> cabal-web or cabal-ui
  • TODO: any more?

contrast with filecoin

• github/wirelineio
  • WNS
  • WPN
  • Wallet
  • WireBox
  • Wire CLI

forked from moloch dao

• github/dxcollective
  • DAO

Required

• Name (github, npm)

  • dxos
  • decentOS
  • collectiveOS
  • peerOS
  • co-*?
  • DXOS
  • swarmOS

• Design/Architecture/Roadmap

• Charter, long-term vision, manifesto