fedwiki / wiki-client

Federated wiki client-side javascript as a npm module.
Other
115 stars 36 forks source link

add full internet toggle to footer #294

Closed WardCunningham closed 1 year ago

WardCunningham commented 1 year ago

Our federation spans two protocols, http and https.

The full federation is only visible when the origin javascript comes from an http site. Some argue that a more restricted internet is preferable. We would argue that even when this is the case a user must be able to view the full internet if the attribution clause of the CC BY-SA 4.0 license is to be meaningful. This pull request elevates this decision to a check-off in the web page footer.

Screen Shot 2022-11-26 at 12 35 04 PM

This implementation will sense the protocol in use and display a check mark accordingly.

We have not implemented the code that will change protocol but expect it will have a user experience similar to enabling or disabling wiki mode with the adjacent check-off.

We don't know if it is possible to dynamically detect what protocols are supported by a given server. Perhaps this will require a server configuration parameter. In any case we suggest when full internet is unavailable that clicking the full check-off should open an informative about-page explaining the potential violation of license terms.

WardCunningham commented 1 year ago

This pull request seeks a middle ground in the disagreement as to the value of having two protocols. Here I quote my disappointment that I could not read the ongoing conversation from a page I wrote. Here I quote matrix.

image image image
paul90 commented 1 year ago

This doesn't appear to do anything other than add a tick mark that can be toggled.

The real problem is people deploying https only wiki. That problem can only be addressed by getting them to switch to supporting http in their installations, and not redirecting from http to https. And maybe adding an automatic redirect from https to http if the user is not the wiki owner - and subjecting people to endless redirection if a site refuses to allow http!

I would be reluctant to opening the proxy to all, as that risks creating an open proxy.

Bortseb commented 1 year ago

automatic redirect from https to http if the user is not the wiki owner

Where would this be done? A proxy, like traefix or caddy, could do this all on its own? or wiki-client is needed to determine the state of the user being logged in or not?

paul90 commented 1 year ago

In reality that is not something that is likely to be workable.

Looking again at the original proposal:

'full' is not self explanatory - definitely needs a page to explain, probably use an antonym of open (maybe limited) and only show if accessed via https and not the owner.

A toggled tick does nothing, so remove. Maybe replace with a link to a wiki page explaining the limitations, but needs a link to open the lineup using http.

An additional approach maybe to provide hints to an author that the content they are reading will not be accessible to others, and to offer some real options for the reader when the edge of the limited island of federation is reached.

This may include giving pages accessed via the proxy a tint, and at the edge providing links to page that can't be reached, reloading the lineup over http, and maybe using a different origin.

WardCunningham commented 1 year ago

I regret that the user-interface that I suggested here did not include a workable integration with all https implementation mechanisms. This is not my strength.

Bortseb commented 1 year ago

The approach that I was most interested in was what I quoted from you. Is this the bit you are saying isn't workable? I wasn't thinking of adding interface buttons or explanations for what's going on, I was hoping to resolve the issue if possible.

I was wondering... Could a wiki be set up using passportjs (generic OAuth), and treafik or caddy, to only allow authentication over HTTPS, but redirect all visitors by default to HTTP if they aren't logged in (So the neighborhood and everything works)... but then as soon as the padlock is clicked, if on HTTP, then redirect to HTTPS for log in (since it would only be possible over HTTPS)

WardCunningham commented 1 year ago

I suggested the term "full" under the assumption that if the site was showing many sites to be unreachable they might switch on "full" and see if they became visible. Some sites support both protocols but require (as I understand) that the user knows how to edit the url location bar to select the less encumbered (full) internet.

This polarity, check for more, is consistent with the "wiki" link beside it. Check wiki to begin editing and understand that pages can be accidentally changed when edit is enabled.