Beaker: Add "always redirect from HTTPS" to "p2p version available"

[pfrazee]

If the user clicks on "P2P version available" and redirects from HTTPS to Dat, there should be a followup prompt to remember that action and automatically redirect in the future.

[pmario]

Hmmm, ... I don't like popups, and programs, that try to guess my needs in the future .. So the options for me should be:

1. Not now! Ask me again later (default)
2. Always redirect from HTTPS to P2P if possible
3. Don't redirect and don't show this dialog again

add 1) ... This options shows the follow-up dialog again
add 2) ... This option doesn't show the dialog but gives me a "switch to HTTPS" button
add 3) ... Don't redirect and don't show the dialog again.

The global settings page should allow to re-activate the dialog.

[pfrazee]

@pmario those options are good. I think we can do this without a popup -- a little button that appears in the same place that "p2p version available" was

[millette]

For normal usage, a redirect makes sense as long as #575 is fixed. When developping, one might want to compare https:// and dat:// access.

[pmario]

When developping, one might want to compare https:// and dat:// access.

hmmm. I'd expect it to be exactly the same. So comparing it would be a test only. ... Or am I missing something here.

[pfrazee]

The idea is that users should choose on a site-by-site basis. So, when you
do the redirect manually, it can ask "do you always want to redirect for
this site?" And the user can say yes or no.

On Mon, Jul 17, 2017 at 1:16 PM, Mario Pietsch [e-mail]
wrote:

When developping, one might want to compare https:// and dat:// access.

hmmm. I'd expect it to be exactly the same. So comparing it would be a
test only. ... Or am I missing something here.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/beakerbrowser/beaker/issues/593#issuecomment-315837293,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNhU3rKGl6-F6xCKMw9XozQ9CbqdU2Nks5sO6UNgaJpZM4OUfV4
.

[millette]

Just noticed a tiny problem, when launching Beaker after an update, this page opens automatically:
https://beakerbrowser.com/releases/0-7-5/?updated=true

Showing that there's a P2P available:
dat://beakerbrowser.com/releases/0-7-5/?updated=true

But there is no content there because of the last / and instead, the content is available at:
dat://beakerbrowser.com/releases/0-7-5?updated=true

Should I open another issue for this?
Should a dat:// url return content if it ends on a slash (before the query in this case)?

[pfrazee]

@millette I actually get content when I visit that URL with or without the slash, and I'm wondering if the bug you experienced was that the page hadnt been downloaded. Is that a possibility?

[millette]

You're right. Now that I return, I see the content at both URLs.

When it was empty, it looked like an empty directory listing (just . and .. from memory).

[pfrazee]

Noted. It tried to behave like a folder, when it should've behaved like a
404.

On Fri, Aug 4, 2017 at 5:57 PM, Robin Millette [e-mail]
wrote:

You're right. Now that I return, I see the content at both URLs.

When it was empty, it looked like an empty directory listing (just . and
.. from memory).

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/beakerbrowser/beaker/issues/593#issuecomment-320370518,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNhU5LNbKdWvxEd-kyX70UiXTs9R8dPks5sU6HZgaJpZM4OUfV4
.

[slinlee]

I'd love if there was a global preference to always prefer dat:// if available. It's even better if it assumes an address is no protocol is dat first.

[dcposch]

The idea is that users should choose on a site-by-site basis.

I think users want less choice and a simpler experience.

What if Beaker just always automatically upgrades to dat:// when available? No config.

It's Beaker. Developers will want to test the https:// version in FF or Chrome anyway.

[mark-halls]

What if Beaker just always automatically upgrades to dat:// when available? No config.

Literally the first option I went looking for in settings when I downloaded it yesterday.
I'm of the opinion that an unused protocol is a dead protocol, especially if it's P2P.
Why should we expect website devs to develop with dat in mind when it isn't the first thing the browser asks for?

[pfrazee]

EDIT: this didn't happen, pls ignore

---

One thing we're kicking around right now is the web:// scheme (aka the app:// scheme, but now we're thinking web://) and this has led to some relevant ideas.

The purpose of the web:// scheme is to create user-configurable DNS. We want all Web software to be customizable. If users couldn't remap the DNS, then a link to https://github.com/pfrazee would force them to use github's software, and we'd lose customizability. So, configurable DNS important for introducing user choice.

We haven't deployed the web:// scheme yet because we've been grappling with engineering concerns. Most importantly is the fact that a user-driven DNS wouldn't be global. The concern is, would it confuse users if they think they published at web://mycoolsite but nobody else sees it?

Recently it was suggested that web:// scheme falls back to DNS. This would provide a global backbone to the name choices. Example scenario: if I go to web://github.com/pfrazee, it would default to whatever GitHub has published there -- but then I could override the address with my own software. You could then publish your custom DNS mappings, for other users to see and try.

We realized this DNS fallback concept works best if web:// could map to either https:// or dat://, so that the DNS fallback could to go to the existing Web. This is where web:// becomes relevant to this issue, because it means the web:// scheme is an abstraction over multiple protocols. We could map web:// to any protocol with the basic hypermedia/document behaviors. It could support HTTPS, Dat, and any other Web-like protocol (like IPFS).

Since the web:// scheme abstracts the protocol, it's the ideal place to inject a default preference for Dat. The resolution rules could be something like:

1. Check for a custom user mapping at hostname.
2. Check for a dat:// site at hostname.
3. Check for an https:// site at hostname.
4. Check for an http:// site at hostname.

This doesn't magically solve all problems, but it does give a clear answer for this question about whether to default to dat. Since we're using a new meta scheme, we can set a custom rule without concern.

Ok, all that said -- even with the web:// scheme, I think there's still a reasonable case for an option to auto redirect from https:// to dat:// if possible. It might break some things (and some expectations) but I'm open to it.

[roscoevanderboom]

Default load dat please. That's why I have Beaker. It's a mind shift. Once it's made and appears without thinking, it will become clear how to proceed next....said the wise man to his apprentice.
The way I'm tagging my bookmarks or sharing dat links over telegram, I hardly ever notice the long string of numbers.

[pfrazee]

Okay putting this on my todos

[pfrazee]

This got completed! Full mechanics here: https://github.com/beakerbrowser/beaker/issues/937#issuecomment-430798932