[autonomo.us] GUIs etc, was [Re: 'Alternatives Working Group' on Loomio]

[Eric Wong]

Danyl Strype <address@hidden> wrote:
> On 11 April 2014 19:58, Eric Wong <address@hidden> wrote:
> > The main browsers still depend heavily on components by those companies
> > (or are non-Free, even worse).  Some sites tend to be unusable without
> > JavaScript, and it's hard for a non-JS user to know what's missing when
> > much JS is obfuscated (or the user isn't a programmer).
> 
> I realise this is a bit of side issue, but just for the record, use of
> "Javascript" is not in itself a problem, as long as the scripts are
> libre. Obfuscated scripts (whether in "Javascript" or any other
> language) are a problem, but not a reason to avoid using a GUI or a
> browser:
> https://www.gnu.org/philosophy/javascript-trap

I don't disagree with that article.  But for me, it's easier to disable
and avoid JS entirely.  Keeping JS enabled would be too much effort to
review code for security, performance and license concerns.  It's not
practical or even possible for me to competently review all the code
I might run.

Unless I'm involved with the development of a certain project, I try to
only run software from Debian stable/main.  This means I've outsourced
license/Free-ness checking to Debian, and the software is usually
without showstopping bugs.  I also try to use smaller, easy-to-hack and
build software which I am capable of improving.

> > Forum/blog sites mostly have different commenting
> > mechanisms and account systems.  The standardized ones tend to be
> > non-Free/centralized; the decentralized ones have little adoption.
> 
> I agree this is a problem, but I think it's rather unfair to blame the
> lack of agreed standards for federated social networking on browser
> makers. That would be like blaming them for Flash. The decision to
> adopt Flash as a de facto standard was made by website builders, not
> browser makers, who actively worked on the HTML5 <video> and <audio>
> tags to replace Flash.

I'm not saying it's only browser makers.  HTML itself was meant to be a
publishing platform, but eventually grew to be interactive.  I suppose
it's easier to advertise and generate revenue on HTML sites than
plain-text gopher and mailing lists, and unfortunately much of the
web is advertising and profit-driven nowadays :<

Keep in mind most of the popular message boards and forums mainly limit
users to text with limited formatting options, and no JS for security
reasons.  In other words, if random users cannot be trusted with JS,
why should we trust the webmasters?

> Mozilla have been actively working on
> BrowserID/ Persona, which implements decentralized authentication is a
> way that provides more privacy than using an OpenID host, and it's
> been adopted by most browsers, but it hasn't had much uptake by
> website builders. Loomio have implemented it.

Persona seems to be (nearly?) dead with few supporters.  The HTTPS
requirement put me (and probably many others) off from hosting myself (I
do not wish to support the CA system).  There also seemed to be no easy
way to get it working with command-line tools such as curl.

> Loomio are actively working on building in seamless email gateways, so
> that a user can interact with a Loomio group as if it were an email
> list. The challenge is to implement the decision-making functions in
> email - each discussion can have one proposal running at a time, to
> which users can reply with 'agree', 'abstain', 'disagree', or 'block',
> and give a short position comment. If you would like to give them the
> same kind of detailed feedback on your needs as a text-only user that
> you've shared with us, I'm sure they'd be happy to work with you to
> make sure Loomio meets them. They are also working on an SMS bridge,
> so text-only interaction is a priority for them.

Cool.  I'm not sure how to best handle decision-making functions in
email (or much with Loomio).  Most projects I work on have a benevolent
dictator and maybe some lieutenants, so it's mainly convincing folks
higher up[1].

Maybe the Debian bug tracker is a good model, though.

Having a low barrier to entry works for me:  I reply to Debian bug
reports just by keeping the BTS address in the Cc.  Nothing to sign up
for and no passwords to remember.  Likewise with git and Linux kernel
development where no subscription is required to contribute; anybody
can email patches or bug reports to the relevant lists and maintainers.

[1] - I also tend to focus on objective and easily-measurable aspects
      such as obvious bugs and performance issues, not subjective
      aspects.

> > Anyways, I am working on making mailing lists more accessible and to
> > encourage drive-by participants for some lists I run.  Hopefully I get
> > it in a usable/demo-able state soon.
> 
> That sounds great. Let us know when you've got an alpha we can try out.

Will start a separate thread later.