testing some changes to a public-inbox .onion

testing some changes to a public-inbox .onion

[Eric Wong]

WITHOUT reading meta@public-inbox.org, maybe some of you
can spot some differences :)   You'll need to use Tor
to access .onions, of course:

       http://hjrcffqmbrq6wope.onion/git/

Tested with Netsurf and dillo.

People with machines powerful enough to run Firefox
(or Tor Browser Bundle) can use "View -> Page Style" to
adjust colors.

Unfortunate downside is current page rendering on the
server-side is 10-20% slower than before.

And there's a big fairness problem with the current
implementation of bl^H^Ha "new feature" :>

So I'll need to address the fairness problems before I can
comfortably deploy it on the non-Tor endpoint.

Re: testing some changes to a public-inbox .onion

[Johannes Schindelin]

Hi Eric,

On Mon, 21 Jan 2019, Eric Wong wrote:

> WITHOUT reading meta@public-inbox.org, maybe some of you
> can spot some differences :)   You'll need to use Tor
> to access .onions, of course:
> 
>        http://hjrcffqmbrq6wope.onion/git/
> 
> Tested with Netsurf and dillo.

Nice.

Do you also plan on taking care of the regular thread view? I still find
it *very* hard to navigate it, and I have to admit that I am spoiled by
the web UIs I use regularly: an aesthetically pleasing interface does
contribute to my joy.

Thanks,
Dscho

> 
> People with machines powerful enough to run Firefox
> (or Tor Browser Bundle) can use "View -> Page Style" to
> adjust colors.
> 
> Unfortunate downside is current page rendering on the
> server-side is 10-20% slower than before.
> 
> And there's a big fairness problem with the current
> implementation of bl^H^Ha "new feature" :>
> 
> So I'll need to address the fairness problems before I can
> comfortably deploy it on the non-Tor endpoint.
> 

Re: testing some changes to a public-inbox .onion

[Eric Wong]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 21 Jan 2019, Eric Wong wrote:
> >        http://hjrcffqmbrq6wope.onion/git/
> > 
> > Tested with Netsurf and dillo.
> 
> Nice.
> 
> Do you also plan on taking care of the regular thread view? I still find
> it *very* hard to navigate it, and I have to admit that I am spoiled by
> the web UIs I use regularly: an aesthetically pleasing interface does
> contribute to my joy.

Hi Johannes,

Do you have suggestions which work with non-JS browsers such as
dillo and Netsurf?

I'm not sure how much free time I can dedicate to UI issues,
which tend to be a very personal choice...  MY idea of a
pleasing UI is: fast on a small, old laptop (where 24-bit
color is unusably slow), using GIGANTIC fonts on a black
background 8-)

The thread skeleton could probably use tables to make
line-wrapping more readable when wrapped on small screens
(w3m couldn't wrap <pre>, but dillo does)

Otherwise, perhaps having a larger set of supported + stable CSS
class/id names to enable user-side customizations would be
possible.

Fwiw, the $MESSAGE_ID/t.atom endpoint also supports Atom threading:

	https://tools.ietf.org/html/rfc4685

So I imagine it would be easy for a UI expert to build on
top of that.

The current thread view also works nicely when my connection
drops, since all the articles get linked to anchors on the
same page.

> > And there's a big fairness problem with the current
> > implementation of bl^H^Ha "new feature" :>

Did you notice the unique new feature?  It's not something I've
seen anywhere else, and it might not be obvious regardless of
browser you use.  The thing I'm referring to has a "debug log"
at the bottom of the page :)

So I think my (limited) time would be better spent making sure
performance is top notch so others can build fast UIs on top of
it; and there might be something else along those lines in the
pipeline...