ktprograms
commented
2 years ago The problem seems to stem from the fact that the lbry:// URI format is not acceptable as a URI, so browsers don't seem to handle it properly.
Working with an example LBRY URI of lbry://@Odysee:8/Odysee-Android-App:1, we can see the following violations of the standard (looking at https://en.wikipedia.org/wiki/URL#Syntax)
There is the start of an authority component, which is meant for userinfo+host+port, but is being used as:
- An empty userinfo
- Followed by an
@, which is supposed to be part of the userinfo - The channel name where the host should be
- The claim id where the port should be, in this case a number but it can also be a letter, which would be even more in violation of the standard
| This gets parsed as the following by browsers: | Browser | Result |
|---|---|---|
| Safari on iOS Simulator | lbry://odysee:8/Odysee-Android-App:1 |
|
| Safari on macOS | lbry://Odysee:8/Odysee-Android-App:1 |
|
| Firefox (on macOS) | lbry://@Odysee:8/Odysee-Android-App:1 - This is the only one that shows the original URL |
|
| Qutebrowser (QTWebEngine aka Chromium) on Linux | lbry://@odysee:8/Odysee-Android-App:1 - Note the lowercase host, as is the standard for a hostname |
|
| Epiphany (WebKitGTK, same engine as Safari) on Linux | lbry://Odysee:8/Odysee-Android-App:1 |
Using lbry:@Odysee:8/Odysee-Android-App:1 works correctly on all browsers (except that the LBRY/Odysee apps can't handle this format), as URIs without an authority can have any characters in any order.
tzarebczan
robster7674
For whatever reason @ symbols are stripped when trying to paste in to the safari workaround
This should even work for blacklisted words like covid