Describe the bug

When viewing the download page on orchid.com, there is text "(You can follow our build instructions here)", under the Android heading.

The "here" is a link to the README.md for the master/app-android folder of this repo. This README doesn't exist, so a user gets the cute star-warsy "these are not the droids you're looking for" Jedi mind trick thing.

The link in full is https://github.com/OrchidTechnologies/orchid/blob/master/app-android/README.md

To Reproduce

Go to https://www.orchid.com/download.
Click "here" where it says "You can follow our build instructions here".
See the standard cutesy github 404, this is not the web page you are looking for.

Expected behaviour

I expect to find a nicely written document explaining how to build an apk using Android Studio.

Screenshots

Since you asked...

Device information:

Not applicable.

Additional context

Maybe I will see if I can get it to work in Android studio, and submit a PR.

Hope you're all well.

Interesting... when I reorganized the README files--which included dropping markdown, which would have broken that link anyway... I have commit access to the website, so I've made the link more generic, but to the same content: it now links to the app-android folder--I accidentally had forgotten to push the Android one :(.

FWIW, the build instructions are ridiculously simple and generic / common: like, the "instructions" are essentially "go into the folder and type make" ("duh", right? ;P). I had included some extra information that was mostly a reminder to install the Android NDK. You (of course) also should have read the top-level README.

On such note: Orchid does not (and maybe "will not"?) support building with Android Studio. We use a cross-platform UI framework (Flutter) and have a cross-platform build system that works identically for every target, rather than using one-off platform-specific development setups designed around the use of bespoke IDEs.

If you would like to use Android Studio--or any other IDE you are familiar with--as your editor, I would recommend finding/developing a plugin that allows you to "just run make", as then you will be able to work with any number of open source C++ projects, none of which would normally have Android-specific builds.

BTW, are you still trying to figure out how to use a VPN to somehow provide payments to LivePeer? Because, if so, I'm going to propose that we set up a time next week so we can sit down for two hours and I can teach you how to interface with Ethereum contracts and how to load our dApp, because it has gotten to the point where you've filed so many weird issues and pull requests and caused so many internal meetings and discussions where, if it weren't that it would feel I shouldn't "reward" this (particularly given how painfully busy I have been the past few weeks), I'd just go ahead and submit a pull request to your project to add the required functionality myself, as I can't imagine it would take more than an afternoon to do this correctly (and it would involve using absolutely none of our code, as a user shouldn't have to configure a VPN to stream a video, and as I've said before: 99% of our code is about networking, not payments... payments are literally just "you call a function on our lottery contract"). Like: "let's just knock this out and be done with it", as then you can have lottery0 support ASAP and can move on to the fun of economic modeling!

I'm going to propose that we set up a time next week so we can sit down for two hours and I can teach you how to interface with Ethereum contracts and how to load our dApp

Hey, thanks for this kind offer... I took the liberty of reaching out on your email address shown on your github profile, in order that we can fix a time. I'm quite comfortable at interfacing with Ethereum contracts :) but I would certainly appreciate a tour of Orchid's contracts, and loading Orchid's dApp.

Livepeer project always welcomes PRs to its main github repo, and I'm certainly very happy to share any context you need, and help onboard you to developing on Livepeer, in order to support.

To start, I would recommend following the "build-from-source" instructions as part of recently updated docs... they should be quite accessible to you, and can help us to test whatever gets built.

Following this, I would point you to this simple explainer of how to operate Livepeer's software at a basic level... by invoking the Broadcaster.

For general context about Livepeer, I would point you to the Livepeer Primer.

(As I said: I don't feel like it is appropriate to "reward" people who use a lot of my time with a PR for the sole purpose of hoping they will stop using my time, whether or not it is intentional or malicious, as it opens an attack vector that I know gets abused as I work in somewhat large communities: I think the meeting is as far as I would be willing to go, particularly "given how painfully busy I have been the past few weeks". One maybe-depressing thing to realize--which a lot of people even inside of Orchid find counter-intuitive, but which I hope will maybe become clear after I explain to you how to just quickly do this integration--is that Orchid's mission isn't actually helped by this kind of integration, so this is charity work ;P.)

(BTW, I am not sure what the goal of linking to your build instructions was... I was curious why you thought they were needed, so I decided to do what I would normally do--check your code out, avoid wasting time on the documentation, and assume it should compile using standard tooling--and your project worked fine by "just running make"? I had to install some library dependencies, but I did it by standard error-driven development practices. I then thought I would read your documentation to see what it might be for, and I will note very strongly that this install_ffmpeg script--which I thankfully would not have run without reading it first--is NOT OK as it both spams the user's home directory and does destructive global make install steps... you should have a giant red warning on that!)

Yeah, the spamming the user's home directory can be annoying. I think most people who run this process, tend to do so under a separate login, or on a dedicated build server.

I acknowledge that you are providing charity here, however I feel there is some additional context that I would like to share ahead of a call. It might appear a little "involved", but I have no doubt you can wrap your brain around it.

It's my effort at convincing you that "by the byte" is appropriate in this case. Wish me luck!

Objective

So, let me start with clearly outlining my objective:

to create a mechanism whereby any individual (or collective of individuals) who "perform" any kind of art form, can have a way to share their performance live, and receive payment (or something somehow equivalent to payment) in real-time, from whoever is watching / listening.

The reason that I think now is the time to make something like this reality, is due to the growth in adoption of various cryptocurrencies, which appear to be by far the most open, sustainable and cost-effective payment rails to do something like this.

The Story So Far...

Let me continue by summarising some outputs from my research and prototyping to date, pursuant to the objective above.

Live Video Sharing

First, is around the platform for sharing content in real-time.

Pure Open-source

Clearly there are options around like Mist, and even nginx has an rtmp module, which are both viable options for ways to host livestream content (consume rtmp from e.g. OBS Studio / ffmpeg, serve hls for playback in e.g. VLC / ffplay), and could be extended to include cryptocurrency-type functionality.

Crypto-incentivised

Then there is Livepeer, which has it's own home-grown media server (lpms). This is a core component of the open-source video infrastructure network being created, off the back of Livepeer Protocol.

Livepeer Protocol

The protocol is an experiment in "continuous funding" (think of it like a "UBI-for-video"-like mechanism) for creating "the video layer for web 3", using dPoS on Ethereum L1. Launched in May 2018, it has grown to ~$700m market cap, with a community of over 2.5m token-holders.

Public Video Infrastructure Network

Livepeer's existing public network consists of a decentralised permissionless set of Orchestrator / Transcoders, who offer their services to "transcode" (=re-size) livestream video content in sub-real-time. This allows Broadcasters to serve multiple renditions of the live content, to reach every user regardless of device type or connection speed.

A transcoding network is the backbone of any livestreaming platform, and the existence of Livepeer's working public version is an important factor in my investigation of Orchid, and directly influences decisions between "by the byte" and "by the second"... more below.

Broadcasters pay Orchestrator / Transcoders for this service, using Livepeer's own probabilistic micropayment protocol, which is similar to Orchid's but subtly different to match a different use-case, and also based on Ron Rivest's seminal work on the topic.

Delegated Proof-of-Stake

Holders of Livepeer Token (LPT) are able to delegate their "responsibility", as owners of the public network, by staking their LPT to Orchestrator / Transcoders. This provides Delegators with a share of the mechanically-driven inflation, as well as fees received by that O / T.

Check your wallets, maybe you got some LPT in the airdrop (video explainer, turn up volume for nice sounds). If so, you can delegate your "responsibility" to an Orchestrator using Livepeer's Protocol Explorer and start earning a non-zero UBI-for-video in web 3 :)

Conclusion

So, to conclude this section on Live Video Sharing, you may have guessed by now, but given this context around Livepeer, and the deep connections it has to Ethereum, I am resolved to use Livepeer's code base to power the video side of whatever I'm building.

More details about the project are here, in the latest roadmap post from the project's founder.

Payment for Content

So, now we come on to payment mechanisms.

Dirty Client-Side Prototype

I've done some (very) dirty prototyping of client-side Android apps which only a) consume and playback content, and b) send payments from an in-app burner wallet every 1-minute via an RPC endpoint (e.g. Rinkeby Testnet, or L2 Matic / xDai). Codebase for this app is here.

It kinda works, but is inherently insecure because anyone who can sniff the client-side network can easily discover where the content is coming from, and bypass the app's paywall and stream for free (doh!).

Also, there are annoying edge cases where a viewer can end up being able to watch for free forever. And fixing these edge-cases doesn't feel like an appropriate use of anyone's time.

So, while this has been an interesting dirty hacky approach, it has led me to consider more about how to create something more like a "server-side paywall", such that the media server simply doesn't even receive a request, let alone serve any video, unless it knows it's being paid.

Server-Side Paywall

The concept of a server-side paywall came out of a conversation with your friend Jennifer almostlikethat last springtime. It appears to me to be the most logical step, and can provide a "back-end", which if defined and presented clearly, can have multiple competing "front-ends" build against.

Build my own

I certainly acknowledge all your feedback about how Orchid's stuff isn't the thing for me to use, and that I ought to build my own logic to implement something to extend Livepeer, using Orchid's nanopayments contracts to pay "by the (quarter-)second".

But if you will humour me, there are reasons why I have an aversion to going this route.

First, is that I'm not a software developer (you probably guessed, right?). OK, I was some form of software developer, in a past life during Math degree and CS post-grad, so I get the principles, but I'm no practitioner. I envy you, that you feel capable of single-handedly creating the source code to be compiled into a set of instructions to pass into a CPU, to make a computer do marvellous things for humankind... but that's not me :(
Second, I have zero / nil / nada interest in operationalising the maintenance and onward development of a codebase, especially when there might exist things out there which I might be able to "just use out of the box with a bit of config hacking". Things which are developed and maintained by people who enjoy, and are excellent at, developing and maintaining powerful software. I do acknowledge that perhaps this software might not be optimised for my specific use case, but that's also fine, as long as it can "do the job", even in a round-about way, and perhaps demonstrate (with rough edges), how things could potentially work... and (in my dreams) to even influence a roadmap so that any rough edges can be smoothed off.
Third, is that if I was going to build something like this myself, I'm not sure I would select Orchid. There are multitude of L2 payment solutions emerging, with low-enough fees to make e.g. 0.1¢ per second actually feasible. zksync, Connext, Matic, xDai, Fuel, Optimism, and even eth2 showing some signs that it might deliver... means that there are many options to consider, and I've tried them all, when considering going the "Build my own" route. Sadly, Livepeer's Probabilistic Micropayments stuff is optimised for payers with big budgets, which is kinda the opposite of what I'm doing, otherwise I'd clearly be using that lol. From what I learn from your colleague Justin, Orchid's payment system has been designed for a more consumer entry-level user-base.
Fourth, crucially, and finally (on this), is to share with you, that it's complicated enough to ask a performer "how much do you want per minute per viewer", without also having to ask them "how much per minute for a 4K / 3840p stream", and "how much per minute for a 1080p stream", and "how much per minute for a 720p stream", and "how much per minute for a 360p stream", and "how much per minute for a 240p stream", and "how much per minute for a 144p stream". You clearly want to be able to charge less for people consuming lower quality (bitrate) renditions, and charge more for higher quality (bitrate) renditions... it would seem equitable.

Livestream Thumbnails

Early concepts in consumer viewing product came up with the concept of "livestream thumbnails", allowing users to pay tiny amounts for tiny renditions, which will help them to select which channel they want to watch...

Here's a mockup of how a Livestream Consumer App might look, with livestream thumbnails at the bottom: output

I'm afraid that things could get messy and complicated quite quickly, to ensure that all segments for all streams, big or small, are being paid for, not to mention the different pricing models, which might change throughout a stream, e.g. as a user's bandwidth gets squeezed, and they have to switch to a lighter rendition.

Use existing stuff

So, all this brings me to the crux... which is that what I desire to do, is:

avoid writing any software myself, and instead focus on doing what I love which is ideating, architecting, testing, building community around powerful software.
build "on top of" / provide more validation of / give support to: existing projects building powerful payment tools for accounting for tiny stuff, enabling more powerful use-cases for independent end-users.
use something which already appears (at a high level at least) to be able to charge "by the byte" for data crossing some kind of threshold, whether those bytes come from the open internet, or a Livepeer Media Server.
demonstrate the power of a Livepeer + Orchid combo, where your viewing costs are proportional to "data usage", which is a well-understood concept.

MVP / Proof-of-Concept / Dirty Prototype

So, in simplest terms, and based on my (admittedly incomplete) understanding of how Orchid works, the kind of hacky proof of concept I've been itching to try to "Frankenstein's monster" together, is something looking broadly like this.

Ingredients

Taking Livepeer's simplified single-server multi-rendition media server setup:

And taking Orchid's simplified "pay per byte for relating request / response data" (an image I've drawn from a combination of guesses and assumptions, many / all of which may be incorrect)

Recipe

Run Livepeer and Orchid on the same machine, with appropriate config so that Orchid can only marshall data to / from Livepeer, and that the Client is unable to get access to the content, unless they've got enough onchain funds to pay out the face-value of a winning ticket...

If they do have enough credit deposited, they would be able to a) create a private connection to this one particular Orchid "hop" on the same host as the media server, and b) pay for the livestream video data passing through Orchid from Livepeer.

Summing Up...

Now, I'm pretty solid on what Livepeer does, and I acknowledge that I may have misjudged Orchid's capability (I'm quietly confident you will tell me where I'm wrong!)... and I acknowledge that "[my] problem simply has nothing to do with VPNs"...

My problem is that I want a way to be able to withhold content / data, if a Client does not have money to pay for it, and to provide content / data if a Client does have money to pay for it.

If I could have this by hacking together something like this, then I would a-ok with there being some kind of VPN involved... it would be fine with me, and might even be something that makes an end-user feel more "special" (but I leave this kinda stuff to marketing). I also wonder whether such a connection might make paying for the "livestream thumbnails" much less complicated, if there's just money flowing for every byte irrespective of how many individual livestreams are being consumed.

If I could have this, and observe this working, I would be battle testing it, and showing it off to the world, and writing extensive documentation about how other people could set this up for themselves, and marketing this to performers and content creators (forget NFTs!), all as a way of continuing my work to integrate two major projects in the Ethereum ecosystem, so that we can all be stronger together.

Thank you for getting this far.

First, is that I'm not a software developer (you probably guessed, right?).

@chrishobcroft OK, I honestly don't understand: are you not the developer of livepeer? If you really aren't a developer then this is honestly just such a waste of everyone's time :(.

As for "by the second" vs. "by the byte", I feel like you are now stuck on something that--while I still want to believe I'm correct, based on my extensive-but-not-public background in live video streaming--doesn't actually matter here: even if you want to charge "by the byte", using a VPN is ridiculous: it is not just the wrong solution technically--involving lots of overhead and an incredibly confusing and difficult-to-set up stack which will CERTAINLY require a lot of code to make stable--it is actively user-hostile.

The core problem is that a VPN is something that requires extremely elevated system privileges and is generally "exclusive" (this isn't quite right on some desktop setups, but is right enough to be truth). Think about it this way: I already use a VPN, and I just want to watch someone's live stream... so now I have to 1) disconnect from my current trusted VPN so I can 2) install some piece of software that is going to be granted the privilege to read and modify all network traffic on my computer? WTF, right?

And like, the entire concept is such insane overkill: the correct solution to this problem is that whenever the client wants the next segment--and as far as I can see LivePeer is absolutely still living in 2000-era HLS-land--it pays for it... "plain and simple". This requires a pithy amount of code to implement: all the client is doing is signing the arguments to an Ethereum call that someone else--the server--will do on its behalf: if you have a good Ethereum library, this literally might be a twenty line of code "full integration".

And sure, if you aren't going to use this crazy VPN stack, I totally accept "why use Orchid?"... well, I want to make sure you really really understand this: I didn't try to sell you on using Orchid! You using our payments layer or our VPN stack (in the way almostlikethat talked to you about) neither helps our mission of private and censorship-free Internet communication nor does it use any of the parts of our system that happen to like, make our token valuable (to the extent to which that is a nice side benefit).

Now, I happen to believe that our nanopayments system has sufficient awesome advantages that you would want to use it on top of "zksync, Connext, Matic, xDai, Fuel, Optimism, and even eth2" (which is how we actually use it: lottery1--which isn't quite ready yet--runs on top of Matic/xDai), but it isn't worth it for me to try to sell you on that... I agree that Matic would also be easy to integrate, and so you should just do that: your users will thank you over this attempt to abuse a VPN into a billing system.

OK, acknowledged. I had always considered it could seem like overkill, but that it would be acceptable if it were to "do the job" without any new code needing to be written / maintained... even in an incredibly esoteric and user-unfriendly way... but which would demonstrate both protocols in all their glories... almost as an art piece, doing something that has never previously been done (however inelegant it may feel), but which might help shift observers' minds in new directions.

I also wondered whether squirting heavy video through OrchidVPN, and payments for heavy video through lottery0, might be an interesting way to start to demonstrate higher volumes of usage than what it's achieving right now marshalling html around.

To answer your question, no, I am not "the" developer of Livepeer. I am part of a community of contributors building on Livepeer Protocol... researching, prototyping, developing, testing and operating the software on the public network. It's kinda like an open DAO, with a participation-based reward mechanism, staking, governance and micropayments, to run video-related-IaaS, paid for in ETH.

In other news, make in orchid/app-android appears to be confidently chugging its way towards enlightenment... had to install rustup whose absence caused env/setup-lnx.sh to fail... I'm learning about "error-driven development practices" - so, thank you!

Yeah: Rust is a weird one because one doesn't generally install it using your system package manager, and so I don't attempt to help automate its install, and instead I just mention it in the readme (in case anyone reads it, which I wouldn't really expect) as part of the high-level dependencies. I was somewhat sad about this, and personally disagree with the way Rust packages their toolchain (I disagree with them a lot).

To hack on any Orchid sub-project, you need to have the usual (complete) set of GNU build tools installed (such as autotools, bison/flex, make... you know, "the works" ;P) and (specifically) clang (I'm truly sorry... maybe one day we'll support gcc). Some of the build scripts for our dependencies use Python (I think only 3.x), one insists on being built using meson/ninja, and we use a couple libraries that are written in Rust.

I do have a way to automate its install in env/setup-dkr.sh--which installs Rust and the Android NDK: this is what I use for building in pristine/empty docker containers--but this isn't something I would ever feel good telling a developer to run as it is a somewhat destructive update to their system that isn't using their OS's official package manager... like, I would be pissed if I were told I needed to run that in order to compile.

I am allergic to docker. I just don't see that the added complexity is worthwhile. For me, it's easy enough to just deploy a slimmed down virtual server which looks the same as your host OS, no need to learn a new tool.

I also (probably irrationally) dislike Rust, and I've only ever used it as a dependency for building software from source...

I also wondered whether squirting heavy video through OrchidVPN, and payments for heavy video through lottery0, might be an interesting way to start to demonstrate higher volumes of usage than what it's achieving right now marshalling html around.

I realize you might have gotten told something different about this by other people at Orchid in the past (interestingly, I believe none of whom are still working here?) but it turns out that driving high volumes of payments--even in the form of "VPN traffic"--doesn't actually cause usage of the thing that drives value to the Orchid token: that is entirely based on people doing truly random selection from our directory contract... and so if you are merely using our nanopayments layer--or are "merely" using our VPN layer but with a specific chosen server / alternate directory--you end up using our software but aren't really "helping Orchid". Now, I'm totally cool helping other projects: one of the reasons our stuff is open source is so that it can be used by other people (and I have friends who have already benefitted from this), but it always matters to me to feel like I'm "fighting for the user", and so I care to come up with solutions that I don't consider to be "actively user-hostile" (which I do truly believe "using a VPN as a billing layer for video live streaming" would be for my stated reasons, all to save what I also truly believe to be--if you have a good Ethereum library that makes signing ABI encoded tuples easy--only about 20 lines of code ;P).

Now I'm installing gradle...

Thanks for the 20 lines of code thing... I think it's helping me clarify the broader picture. Livepeer uses go-ethereum, which I believe is an adequate Ethereum library, if we're judging ;p

Going to bed. Don't want to accept licenses.

Checking the license for package SDK Patch Applier v4 in /home/orchid/orchid/app-android/licenses
Warning: License for package SDK Patch Applier v4 not accepted.
Checking the license for package Android Emulator in /home/orchid/orchid/app-android/licenses
Warning: License for package Android Emulator not accepted.
Checking the license for package Android SDK Platform-Tools in /home/orchid/orchid/app-android/licenses
Warning: License for package Android SDK Platform-Tools not accepted.
Checking the license for package Android SDK Tools in /home/orchid/orchid/app-android/licenses
Warning: License for package Android SDK Tools not accepted.
Checking the license for package Android SDK Build-Tools 29.0.2 in /home/orchid/orchid/app-android/licenses
Warning: License for package Android SDK Build-Tools 29.0.2 not accepted.
Checking the license for package Android SDK Platform 29 in /home/orchid/orchid/app-android/licenses
Warning: License for package Android SDK Platform 29 not accepted.

FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':compileReleaseJavaWithJavac'.
> Failed to install the following Android SDK packages as some licences have not been accepted.
     patcher;v4 SDK Patch Applier v4
     platform-tools Android SDK Platform-Tools
     emulator Android Emulator
     platforms;android-29 Android SDK Platform 29
     tools Android SDK Tools
     build-tools;29.0.2 Android SDK Build-Tools 29.0.2
  To build this project, accept the SDK license agreements and install the missing components using the Android Studio SDK Manager.
  Alternatively, to transfer the license agreements from one workstation to another, see http://d.android.com/r/studio-ui/export-licenses.html

  Using Android SDK: /home/orchid/orchid/app-android

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 3m 24s
make: *** [makefile:67: build/outputs/apk/release/app-android-release-unsigned.apk] Error 1

Now I'm installing gradle...

FWIW, I agree this sucked. On macOS, it is obvious how to install a current version of gradle using brew; but, on Ubuntu, it wasn't, and I was apparently using a PPA? The gradle people really want me to use a "gradle wrapper" (which I've been avoiding, as it doubles down into a situation I hate involving the usage of gradle), so I'm just going ahead and adding support for that to Orchid's app-android.

Going to bed. Don't want to accept licenses.

In another issue you were wanting to use Android Studio, which required you to accept all of these same licenses, so I don't understand... this is essentially table stakes for doing Android software development. (Annoyingly, I'd forgotten that these were required, and so you are now a step ahead of where I was in my attempts to automate the Android SDK installation, and I thereby can't legally finish.)

FWIW, I agree that it is depressing that all of this isn't more "open": my personal intention is to eventually figure out how to entirely remove the usage of gradle--and the associated Android SDK gradle plugin--from my build system, but sadly that is almost impossible as, if nothing else, third-party dependencies--even Flutter packages--end up wanting to be built with "standard Android tooling".

But like, until some pretty massive amount of work can be done to pull apart and rebuild the Android build environment into orchid-env, the current status is that you either have to agree to the terms of service for the Android SDK so you can compile Orchid or you will need to find someone else who is willing to agree to those terms of service (such as us, or GitHub) to compile Orchid for you :(.

FWIW, I actually don't mind accepting licenses, I was tired, and grumpy that it still wasn't working, and I lost my temper a little, and I apologise. Passion huh?

In another issue you were wanting to use Android Studio

As above, I don't mind accepting licenses. But also, I wasn't necessarily wanting to use Android Studio, it was more of a question about whether I should / could just load this up and compile using Android Studio (which is an IDE that I do have some familiarity with).

Back to the server-side paywall concept. I really don't dispute that your proposed solution may be elegant and effective, if I considered it appropriate to sell livestream "per segment", and if I wanted to create more code in this world.

So, risking pissing you off by wasting more of your time, I do have some further things to share on this, to explain why I still don't want to do it, which you don't have to read.

Segments vary in duration... which makes the pricing of them a complicated moving target. But in a world where I'm being metered by-the-byte by "abusing" a VPN into a billing system, this complexity is gone.
I feel unable to effectively evaluate Orchid's payments, which I would need to do in order to decide if I agree with you that your "nanopayments system has sufficient awesome advantages that you would want to use it". I can't dispute what you say though, because I have zero data to go on.
Existing OS video players (e.g. ffplay, hls.js, exoplayer) would need to be hacked to be able to include logic for signing transactions, which of course is possible, but leads me on to my next point, which reiterates a previous point.
I don't want to write / maintain / audit any code at all. I know that for you, it's incredibly easy to envision just sitting, laying out the syntax, running it, testing it, tidying it, checking it in, releasing it, onwardly maintaining it. But for me this represents the accumulation of "digital baggage", which I go to great lengths to avoid.

So, fully cognizant that OrchidVPN + Livepeer is a "sledgehammer to crack a nut", and if I have understood this stuff correctly (and I'm still waiting to be told that I haven't), then I believe that it's possible to put together my aforementioned "Frankenstein's monster", and use existing well-developing and well-maintained software, albeit configured in ways which were not intended, and my nut would be cracked.

It's also worth, I think, considering other user profiles in this, than merely "the creator" and "the viewer"... but more like in a DRM context, a "livestream media rights licensor" and a "livestream media right licensee", both of whom would likely insist on some kind of VPN solution to protect the content being shared between them, and if that VPN solution can also be a billing solution, then wouldn't that be elegant? I accept that this does little to aid independent sovereign individuals to build from the grassroots, but as a solution for those who create content, it would represent "motion towards" a better place than we are in right now with the traditional world of live media rights and publication :)

I've been following Orchid for a very long time, since your original WP, and it's always been something I've put in the box of "nanopayments for data", with this whole "let's make a VPN solution" thing being a logical first baby step on the path to nirvana, which would be some kind of global mesh-network without central points of control / failure / censorship (does everyone still have their fingers crossed that we can achieve this?)... and in such a model, sources of video data, like my livestreams that capture from camera at 30Mbps would be automatically monetised, in the event that anyone is requesting the data from me. But for now, and I'm not the only one asking this, I'm still in the dark about "does Orchid actually work".

I'm not asking for validation of whether you think this is the "correct" thing to do, I'm asking for confirmation of whether I have broadly understood the high-level workings of Orchid, and whether you are aware of anything that literally makes my quest here impossible, before I spin up a couple of VMs and starting trying to hack something together with some pre-compiled binaries?

Draft architecture looks like:

server0 - running:
- livepeer's broadcaster / orchestrator / transcoder
- ffmpeg to publish a test rtmp signal into livepeer (so that there's something to watch).
- orchid's linux server (orchidd?) - configured to only be able to request / receive content from livepeer
client0 - running:
- orchid's linux client (orchidcd?) - configured to connect to server0, and with wallet etc.
- ffplay to request content from livepeer on server0

Please attack this with an objective "technical (im)possibility" viewpoint, and without a subjective "correctness of solution" viewpoint... and I beseech you, don't tell me to write code, because then I get sad that I'm not a genius developer like you.

I wrote a long response to some of the things you said--to be clear: I did not do the thing you wanted, but backed up why your new objections to the architecture I have described aren't actual issues, due to the roadmap of things I have for you on my payments side quest--but I actually am coming to the belief that helping you in any way is just going to do the world a greater disservice. I went back over all the notes of all the interactions that you and Livepeer have had with Orchid over the past two years (I had forgotten it was even this long by now...), and I will not help your project. If you had simply come to us and asked us to help you integrate payments, I would have probably just done it for you: I have a lot of background in video streaming tech and I'm good with other people's codebases and this is such an "easy problem" that simply coming to me as an end user would have ended in a better place than were we are today.

Instead, I am going to say one more thing in the hope of discouraging you from doing this, as I want you to understand that I consider what you are doing evil--"evil" in the same way I have looked at software projects that, to do something a bit faster or easier have cut corners and required users send them dangerous credentials like passwords or keys, or have insisted on getting access to too much data about users by putting work on a server that shouldn't be on a servers--and then, after, I want you to never speak to me ever again.

Orchid's current client--which is but one way of using Orchid's current protocol--is a VPN client. A VPN client requires extremely elevated permissions on a user's computer to execute, as it is capable of intercepting and even modifying the user's network traffic. This alone should be enough to show why, unless you absolutely can't come up with any other way of accomplishing your goal, you should not use VPN technology "willy nilly" (and I say this as someone who has made the tough choice in the past to ship software--Cydia Extender--which used local-only VPN tech as an alternative to designs which were even more user hostile, after carefully proving I had no other option and spending months of development on it).

On our current target platforms, a VPN is also somewhat "exclusive": you can't have more than one operating at a time on, for example, iOS. This means that a user who is relying on a chosen VPN for security or even merely access while on a hostile network would be screwed by any solution that requires them to use a bespoke VPN. (I mentioned this in one of my earlier comments.)

However, what you want to do today is way worse than even that: Orchid's client does not currently support any kind of "split tunneling"; this is on my todo list, but I haven't built it yet. This means that, as it stands, even if the user trusts Orchid's software to function correctly, it fundamentally is taking all of the traffic on the user's computer and routing it to some exit server... which you want to be your server... where you will be able to intercept and even modify all of the user's traffic... and without any ability for the user to audit the behavior as it is running on a server... and not because they need VPN service (the tradeoff they make when using our software as intended), but because they want to do video streaming, and you believe that writing code is somehow bad.

I simply cannot abide any of this. And like, it isn't as if I am not giving you alternatives, or being unwilling to help you do this correctly... you just don't want to do it correctly. Hell: if you even simply put aside the idea that being an armchair systems integrator is giving you some kind of unique insight here and seriously asked me to help you learn to program so you can do this correctly, this is such a simple thing to do that I might have even have been willing to do that... or maybe (as one-on-one instruction is likely not the best use of time) I could have done this integration with someone from Livepeer as some kind of joint live steam event (as I really do believe it can be done in a single afternoon). But you truly seem to be adamant in your solution here (something I even am seeing in notes of your past interactions with people from Orchid), and are actively insisting on doing this in a way that is user-hostile. No... just no: go away.

Oh man, I really am just trying to learn what Orchid software does, and how it works, and play around with it, observe it for myself... because right now I don't understand it, and I wish to understand it, and I also wish to help communicate what it does to other people, so that they can understand it.

So, I'm doing this in a context where I can relate it to a world which I do understand...

I really am sorry that my actions have caused you such pain.

OrchidTechnologies / orchid

Broken link to apk build instructions from orchid.com/download (no README) #83