Commits to the master branch should automatically update the live site without any other actions. This allows GitHub to be used as an editing interface.

This is unrelated from continuous integration and/or integration tests.

It'd be cool if on the homepage or somewhere on the site there was just a feed of all of the commits happening at LBRY across all repos.

If possible, it would be cool if lbry.tech had a feature similar to the lbry.io FAQ, which links directly to the relevant source file in GitHub.

Example: https://lbry.io/faq/earn-credits

The link is at the bottom.

Using the wallet_send method, the daemon returns a MemoryError.

{
  "error": {
    "code": -32500,
    "data": [
      "  File \"site-packages/twisted/internet/defer.py\", line 1299, in _inlineCallbacks",
      "    ",
      "  File \"site-packages/lbrynet/core/Wallet.py\", line 1101, in _tip_claim",
      "    ",
      "  File \"site-packages/lbrynet/core/Wallet.py\", line 984, in _run_cmd_as_defer_succeed",
      "    ",
      "  File \"site-packages/lbryum/commands.py\", line 2248, in sendwithsupport",
      "    ",
      "  File \"site-packages/lbryum/commands.py\", line 2207, in support",
      "    ",
      "exceptions.MemoryError: "
    ],
    "message": "MemoryError"
  },
  "id": null,
  "jsonrpc": "2.0"
}

Currently at https://lbry-whitepaper.herokuapp.com/

Is whitepaper a separate server? Is there a stylistic break? Or do we integrate whitepaper build into lbry.tech?

The main pages of the website should be renderable via Markdown files located in the content folder.

A sample Markdown file has been added here.

This file contains FrontMatter metadata, but this should only be used on lbry.tech if it is necessary or useful.

@lyoshenka commented on Mon Jan 29 2018

Due to Vuetify being removed, Hook is not currently functioning. Fix the needed parts and test it's functionality. Also make a sample page where this can be tested out.

The daemon requires the image to be a local file. How do we get the file uploaded to the daemon server, or is there another way to do this?

I suspect we'll end up having 20+ of these over time. It'd be preferable to store them in a place other than the top level of the project.

• Links to Github projects
• Bugs - how you can report them etc
• Brief description / list what you can contribute
• Get in touch
• Community -> link to Resources-page
• Link to https://opensource.guide/how-to-contribute/
• Describe the workflows of different projects

• Application Case Study: Spee.ch
• What are Claims, how they work
• URLs, Name Resolution
• DHT?
• How to run wallet server/reflector/search server/chainquery
• Design / branding
• using lbrynet as a library in your code
• Validating signatures on claims

@lyoshenka commented on Mon Jan 29 2018

Have a simple local server with node. Should accept the LBRY daemon parameters and it forwards them to daemon.lbry.tech.

On the homepage? Somewhere else?

• Links to all social medias (reddit, discord, slack)
• Links to source code

Rather than being a markdown file, instead this page should do two things:

• Drive people to whitepaper and API specifications
• Catch-all list of other resource and documentation articles

I'd like there to be a component that supports email collection and adds them to our user database tagged "developer". I say component because I'm not sure exactly where on the site this will live.

Adding the user to our database is relatively simple. Just POST the values email and tag=developer to api.lbry.io/list/subscribe. You can see PHP example code here: https://github.com/lbryio/lbry.io/blob/master/lib/thirdparty/LBRY.class.php#L20.

Establish a base design using Lbry branding, built on Vuetify.

• All Markdown content is contained within a single folder (additional organization can exist within this folder, if necessary or desired, but it should not be necessary to call every file index.md).
• All first-class pages as well as resource articles can be served by URLs that do not include a trailing .html or an indication of the folder structure. E.g. lbry.tech/repository-standards should serve the Markdown file located at resources/repository-stanards.md).

Start with an outline
and assign sections

• Examples?
• Real-life implementations?
• Link to official app source code
• Quickstart?

Metatags, Sitemap, etc.

• Optimize Webpack for production
• SEO (for documentation links etc)

Standards are here.

If there are any pending technology or setup/environment choices, you can wait until those are made to do this.

It'd be good if there were some simple tests that ensured common pages render and return a 200 status code.

More complex or thorough tests could be created for the hook, as well as well the daemon endpoint.

This is the epic issue to collect all changes required to have API documentation work inside of lbry.tech.

After some discussion, there is now some uncertainty as to whether OpenAPI/Swagger is the right solution.

Required properties:

• Web-based display of all endpoints/methods, including parameters, description, and example response signature. Methods should be directly linkable.
• Modern, clean, friendly, usable UI (Stripe is some of the best API documentation I've ever seen / used)
• Method documentation in-code. The documentation tooling should be able to take this documentation and generate the interactive page(s).
• Build-integrable tooling (not sure how this one wouldn't be possible though :)

Ideal properties:

• Identical or similar API documentation standard across repositories.
• Method documentation located in-line with method entries, rather than a separate YML/markup file.
• Handles both CLI and JSON-RPC ways of method calling
• Auto code-gen, live testing, and any other benefits from Swagger.

Other considerations:

• API versioning?

Match links in header + add any desired extras like Sitemap

We will have at least two:

• lbry
• lbrycrd

For now, this functionality can be added with dummy spec files.

Since Vuetify is underutilized in this project, it is the best to remove it. This will make build process faster and the client needs to download less. It also provides more creative freedom.

Some basic design elements needs to recreated, like forms and such.

This issue also concerns #34

• Finish Step 1
• Finish Step 2
• Finish Step 3
• Test on mobile
• Test input validation etc
• Improve styling (whitespace, colors etc)
• Publish on Step 2: How is actually implemented?
• Fix MemoryError on Step 3

@kauffj commented on Thu Dec 07 2017

There's good content here: https://github.com/lbryio/lbryschema/tree/master/docs

At least some of this should also be on lbry.io.

@tzarebczan commented on Tue May 15 2018

@kauffj should we close this as these docs will now live on lbry.tech?

@kauffj commented on Tue May 15 2018

I think this question still remains, but could now live in lbry.tech.

It's not clear that all technical documentation should live in the lbry.tech repo. In some cases, it may make sense for the documentation to live in the project repo and just be imported/displayed by lbry.tech.

By creating a new markdown file, Vuepress will generate an url for that piece of content. This content is only reachable by accessing that url directly. We should make sure that all these pages are linked somewhere in navigation. Or, we can generate a sitemap that has all of these pages linked.

Edit the basic pages to have the same placeholder content as in Overview-page currently.

I want to add <meta name='viewport' content='initial-scale=1, viewport-fit=cover'> to the <head/> for iPhone X support. Reference here: https://webkit.org/blog/7929/designing-websites-for-iphone-x

This is low priority as I don't expect people to visit the site in landscape mode. The rumored upcoming iPad will change this expectation though.

How to implement the existing documentation? https://lbryio.github.io/lbry/

Have a large notification or similar element to display that this website is still in active current development

Five of these divs are unnecessary and mess up what used to be simple flex CSS stuff. Two ids of the same name isn't valid HTML but I don't know if that matters here.

Evaluate rebuilding with Vuepress: https://github.com/vuejs/vuepress

Candidate to move over to lbry.tech: https://github.com/lbryio/lbryschema/blob/master/docs/uri.md

• Placeholder Hero graphic
• Description text

When headers are stacked they can be a little tight, see this page: http://beta.lbry.tech/develop.html

The h2, h3, and p are all stacked right next to each other.

Changes to step 2:

• Separate fields to make clearer which go to blockchain and which are just for image
• Add a couple more default images (Carl Sagan suggested, will come up with others)
• Language should be dropdown
• Omit author
• Description can be two lines and have a default value (e.g. "Check out this image I published to LBRY via lbry.tech")
• License can be dropdown, please default to Public Domain (see https://github.com/lbryio/lbry-app/blob/95a85300dcbc5b5ed96e5f9dd8f5f3c67da147b2/src/renderer/constants/licenses.js)

• Make sure README has correct build instructions
• Basic navigation

Import all existing assets to spee.ch.

In addition to defined pages being editable via Markdown, it should also be possible to create a markdown file and have this correspond directly to resource pages.

For example, a markdown file saved at content/resources/wallet-app-authentication.md could correspond to and be served in a rendered form at lbry.tech/resources/wallet-app-authentication.

At least the Highlight.js has a lot of syntax language highlight scripts that are not needed.

This functionality was removed on redesign, make sure it is implemented again or message if it's not needed.

There's already a Sidebar component ready in Components folder.

Ensure we've done all we can to reduce abuse of the hook. Do we need to whitelist claim recipients? Require certain credentials? etc.

(And whitelist / restrict allowed calls to daemon.lbry.tech)