[kwlug-disc] Callout to CS majors/Other technically savvy klwug listers.

[Paul Nijjar]

On Thu, Feb 07, 2019 at 05:37:43PM -0800, Doug Moen wrote:

> The centralized model (eg, how github works) has the advantage of being
> well known, it's obvious how to set it up. The problem is that I don't
> want to pay for the servers needed to keep the CurvNet running,
> especially if it the project takes off and becomes really popular.
> Creating a business model that pays for the servers to keep running is
> also problematic. It's either advertising (collecting people's personal
> information and reselling it), or you pay for an account, which creates
> a large barrier to entry. Plus it's centralized, so if the CurvNet
> server shuts down, then everybody loses.

> I'd prefer a decentralized model. But where are the servers where the
> content is stored; who pays for those servers? How do you find content
> on the network related to your interests? How much friction is involved
> in publishing content to the network?

Why isn't github that server? Why isn't git the backend?

It sounds to me as if you want CurvNet to be some kind of repository
(a la Debian's apt repositories) or some kind of directory (a la
Yahoo! in the 1990s). Here are some blue-sky thoughts as to how you
might set up such a system for CurvNet: 

- The "database" of information is a git repository. Maybe it just
  points to locations where you can find interesting Curv projects.
  Maybe it aggregates the code for those Curv projects into the
  repository itself. 

- You start this git repo and host it on Github. This can be thought
  of as the canonical repository, where most people go to find Curv
  libraries.

- Say somebody wants to add an entry to the repo. That is a pull
  request followed by a merge. (I wish standard git supported pull
  requests.) You could also do the Linux kernel thing where you have
  subordinates who do much of the project filtering and standards, and
  then you periodically pull those changes into your repo. 

- Oh no! You have given up on Curv and take down the repo. That is
  okay. If somebody else has forked the project then there is the
  chance that the Curv repo lives on. 

- Oh no! There has been a big fight, and now there is a schism as to
  what the repo should contain. So now there is a hard fork and
  multiple repositories, similar to the way you can have multiple APT
  repos in Debian. 

- The frontends for CurvNet would want the ability to point at
  different repos, and have some mechanism for resolving conflicting
  packages. Again, I think APT has solved this problem. 

- Oh no! Github does not offer free hosting for CurvNet any more. The
  backend is just a git repo, so it can be hosted elsewhere. Maybe
  that elsewhere is a server people pay for (at which time you have to
  figure out how to incentivize this payment). Or maybe you find some
  Github competitor which will host the repo for free. The end users
  just (or "just") need to point their repositories to the new
  location.

- Maybe you could also allow repos to be mirrored in the same way APT
  repos are mirrored. Git makes this possible, although maybe it is
  not trivial to do this automatically?

The nice thing about such a setup is that it would be federated in
multiple ways. There could be many different repositories with
different package listings. There could be ways for some repos to pull
information from others. And there would be ways for repos to mirror
each other. There is no "CurvCoin" that you mine to become
unbelievably rich and/or attract VC funding, but that does not sound
like one of your goals.

This may be wholly untenable, or it may be already implemented and
available for you to use. But it sounds to me as if there are some
solutions to this problem that do not require a lot of operational
costs and do not need a blockchain.

- Paul