[Freedombox-discuss] Request for Comments: Agenda Items for 2020 Summit

[hjenkins]

I agree on the need for multiperson videoconference hosting in 
Freedombox. Though, as Jonas Smedegaard says, the hardware demands may 
be beyond many freedomboxes, as far as I know there is no max-spec for 
which Freedombox is designed. The platforms hosted by Debian Social 
(https://wiki.debian.org/Teams/DebianSocial/) do make a decent package 
wishlist.

Jami just (as of October 16th) turned into videoconferencing server 
software. It still does peer-to-peer, too. Separately, there is a new 
"Jami Account Management Server", which does e-mail style distributed 
addressing. It seems to me that these changes put it in-scope for 
Freedombox. The October Jami release is not yet in Debian, but the last 
two versions are in sid and stable. Jami focusses on low hardware and 
bandwidth requirements, so might be a better fit than Jitsi.
https://jami.net/together-the-new-version-of-jami-and-a-new-step-forward/

On https://www.freedombox.org/, it currently states:
"FreedomBox provides a secure, decentralized replacement for WhatsApp. 
Do group chats and audio/video calls from any device."
I think this refers to XMPP, which can be made to do these, sometimes. 
https://wiki.debian.org/FreedomBox/Introduction has a more up-to-date 
version of the leading screenshot, too.


And now to answer to Fioddor Superconcentrado's broader point. I think 
there is a large user group that wants a stable, secure, low-maintenance 
server. A fast-moving all-the-latest-gadgets server is frankly a pain in 
the neck, not just to package maintainers but to the server admin and 
the end users. Most people are a lot less interested in server 
maintenance than anyone on this list. No objection to a multitiered 
contribs/non-free/Yunohost-ports setup, but it should remain possible to 
run Freedombox as a Debian Pure blend.

Debian's twin focus on freedom and stability is not co-incidence. They 
are interdependent. I cannot see any technical reason why 
videoconferencing could not have stable standards; it's a good goal. 
There seems likewise no reason why an e-mail or filesharing or Mumble or 
IRC server should need frequent (non-security) updates. A website should 
generally need such updates only for new content; you should not be 
running to stand still. Tellingly, browsers now brag of their ability to 
turn off web features for privacy and security. I'm not arguing against 
change here. Just no widespread "break everything and redo from start" 
change without very good reason.

Anyone who has looked at, say, Android or HTML5 knows that some changes 
are not in users' interests. Changes "to gather more user data", "to 
implement DRM", or "because we can't make independent decisions, and 
[power-holder] required it" aren't features you can sell to endusers. 
But unfree alternatives are frequently marketed on fashion, not 
features. Fashions are easier to manufacture: "We aren't like the bad 
old competitor! Pay no attention to our similar potential for 
surveillance and manipulation. Our new product is the latest modern 
space where all the cool people are. If you don't use our product, 
you're outdated and you've fallen behind the times. Your friends and 
potential customers will hold you in contempt for your stodgy prudish 
fussy old-fashionedness. Everyone else is doing it". This is the 
software equivalent of "You might think you want a robust, durable 
smartphone with USB ports, good ergonomics and long battery life, but 
really you want a tiny wafer phone that eats batteries, breaks if you 
drop it, and regularly costs you hundreds in replacement parts and 
proprietary connectors, because it is fashionable". Marketing tech by 
playing on fears of being outdated is clever targetting. But no-one can 
adopt everything new, and our adoption criteria need to be better than 
fashion.

Less-free alternatives are legitimately marketed on ease and 
convenience. Freedombox is basically an attempt to make self-hosting 
easy and convenient. Freedombox is what every software start-up wishes 
to be perceived as: independent, private, ad-free, democratic, 
user-controlled, in a political and legal structure which keeps it that 
way. We could point this out, and satirize fashion-shaming social-trap 
marketing. But we are better than fashionable; we have features. Thanks 
to everyone who's added them!




On 2020-11-25 06:30, Fioddor Superconcentrado wrote:
> Sorry for the long report. I hope its structure helps a diagonal read.
> 
> 
> In my humble and still quite ignorant opinion, the most *important
> challenges* for FreedomBox in 2020, Q4 are:
> 
> *Video-conferencing feature*:
> Covid19 has forced masses of people and small businesses online. Those
> newcomers are falling into free-as-in-free-beer SaaSS traps. We missed 
> a
> huge opportunity to serve and grow, and we should catch up ASAP and 
> rescue
> as many as we can. FreedomBox needs a proper video-conferencing 
> solution
> for individuals and small communities. I don't know if I'm biased by my
> personal experience, but I tried to get my daughters to use JSXC and it
> resulted to be way too buggy.
> 
> *Consistency*:
> We're inconsistent! We and/as debianites use Jitsi Meet for
> videoconferencing, but it is not packaged in Debian and due to web
> standards evolving so fast, will likely never be, unless it is granted 
> the
> same exceptional status that browsers have.
> 
> Project *effectiveness* as *relevance* for end users:
> 
>    - This is becoming a general trend: It happened to Docker, 
> VirtualBox,
>    PyCharm, etc. Despite the growth in the amount of packages 
> maintained, more
>    and more popular free software is installable but missing in Debian 
> => It
>    needs a strategic solution at Debian level.
>    - As Debian pure blend this limits us over other solutions. I don't 
> know
>    how far we could/should bend those limits. I believe we could 
> include such
>    software as long as we clearly distinguish what is FreedomBox 
> (Debian) and
>    what are external plug-ins. YunoHost would be a good partner here 
> because
>    they're Debian based as well. If not allowed, we should *consider*
>    prioritising purpose over path/means and become a derivative instead 
> of a
>    pure blend. I say *"consider"* because we might as well decide to
>    prioritise the path over the purpose and remain a limited effort to 
> provide
>    privacy with available hard-certified free software only.
>    - This challenge has technical aspects but it is a political issue.
>    Foundation might push/help to raise awareness of this within Debian 
> (?).
>    - DPL said in DebConf 2020 that Debian was overbudgeted (See
> 
> https://chuangtzu.ftp.acc.umu.se/pub/debian-meetings/2020/DebConf20/9-bits-from-the-dpl.webm
>    at minute 3:00 to 9:30). Well, I guess the problem isn't the money
>    actually, but rather a very constrained list of 
> policy/culture-compliant
>    ways to spend that money. Debian is volunteer-run by definition for
>    independence's sake and thus, we should avoid money to become a 
> vital
>    infrastructure. Instead, it should better remain an optional 
> accelerator we
>    can live without. Foundation might perhaps persuade Debian to spend 
> buying
>    upstream (or from Freexian, see
>    https://www.freexian.com/en/services/debian-sponsorship.html) 
> solutions
>    to problems suffered by Debian (?).
> 
> 
> In my humble and still quite ignorant opinion, in order for Freedombox 
> to
> become a *mainstream consumer* solution we need:
> 
> To *fix* the minimal viable product (*MVP*).
> The basic functionality must work out of the box and the admin 
> procedures
> must be easy to find and execute.
> Find below my suggestions for developer priorities, for more details.
> 
> *Marketing*:
> Strategy: I see at least 2 compatible, but different approaches:
> 
>    - Seek geeks as evangelists for consumers trusting their advice.
>    - Consumer first approach with geek goodies as secondary extra 
> value.
> 
> Numerically-controlled: Hard facts and metrics are key to manage 
> anything,
> if you seek results, and marketing is no exception.
> 
> There was some interest 2 years ago in a marketing team but it diluted 
> (See
> #1944 
> <https://salsa.debian.org/freedombox-team/freedombox/-/issues/1944>).
> Perhaps it can be re-launched?
> 
> To *prioritize* *purpose* over maintainability.
>          Current examples of the opposite:
> 
>    - The apps are sorted by app name (identification) instead of by 
> user
>    functionality (delivered value). See #1859
>    <https://salsa.debian.org/freedombox-team/freedombox/-/issues/1859>.
>    - Self-constraining to be a pure blend (maintainability) over 
> providing
>    a highly demanded, available, free software based, working solution 
> (like
>    Jitsi Meet).
> 
>          Prioritising purpose isn't gratis. It implies some extra 
> effort.
> 
> To *collaborate* with other privacy-focused *communities*:
>         * "On your own, you get faster. Accompanied, you get further."*
> 
>    - Self-hosting: FreedomBone, YunoHost, SandStorm,
>    https://lists.debian.org/debian-devel/2020/11/msg00202.html.
>    - Offgrid: See 
> https://wiki.debian.org/FreedomBox/Design#Similar_Projects
>    - Alternative networks/services: Tor, I2P, Disapora, GNUSocial,
>    Mastodon, Matrix, Protonmail, DuckDuckGo...etc
>    - Privacy Tools Debian Maintainers:
>    https://wiki.debian.org/Teams/PkgPrivacyMaintainers
>    - https://lbry.com, FSF/FSFE/FSF-LA, ...
>    - Current upstream.
>    - Would-be upstream. See
>    https://wiki.debian.org/FreedomBox/LeavingTheCloud
> 
>          We should list such communities on our wiki in order to track 
> them.
> 
> I've tried to set my proposal for *developer priorities* in line with 
> the
> previous view/goal:
> 
> 1. Fix *basic* usage/UX *caveats*:
> 
>    - The easiest path for consumers is *buying a kit*. Our webs still
>    highlights download over purchase or as equivalent options. 
> Consumers use
>    to think that 'download' is more affordable, and when they discover 
> that it
>    is technical and difficult they just give up because they already 
> forgot
>    they can cheaply buy-and-plug. Download should be marketed as a 
> secondary
>    choice because it is a very interesting solution for a secondary 
> target
>    (geeks). It should always be presented as such.
>    - A router reset (caused for example by a power outage) renders the 
> *FB
>    unreachable*. (Q&A doc can help a lot!!) See #1833
>    <https://salsa.debian.org/freedombox-team/freedombox/-/issues/1833>.
>    - Some *asynchronous procedures* cause uncertainty, provoking a 
> feeling
>    of unfinished product. On screen spinners help. We need some helper
>    mechanisms to be able to read progress and report it to the user in
>    real-time.
> 
>  2. Fix *reachability*:
>        Once the consumer has FB running in her LAN and benefits from 
> it, a
> usual step is wanting to share it with family and friends.
> 
>    - Current *networking documentation* is still difficult for regular
>    consumers (magels). Graphical schemes help a lot but the UI still 
> uses too
>    much technical jargon and lacks explanations of consequences and
>    side-effects. I don't yet see a clear overall solution. I can only 
> think of
>    small improvements for specific cases. We need some design 
> discussions here.
>    - *Dynamic DNS is important* because if it fails (it does) it 
> usually
>    blocks Cockpit. Cockpit needs a full DN.
> 
>  3. We should (try/aim to) provide *self-hosted web clients* for
> IRC/quassel, mumble, etc.
>      Some don't even exist. We should ask for them upstream or in
> privacy-centric forums.
> 
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-discuss