The FreedomBox community’s upcoming progress call is this Saturday, October 9 at 14:00 UTC. We aim for our calls to last no more than one hour, although sometimes the core team stays on the call past one hour to discuss additional items.
As always, our team will discuss the latest issues in our software development and community. All are welcome to join the discussion or listen!
How To Connect :
We are using Mumble. Please connect to server mumble.freedombox.org port 64738.
We use Mumble for voice communications to allow residents outside of the United States to participate without running up a phone bill.
You do not need to create a username before hand (just make one up).
No passwords are required.
You can join the call using desktop or mobile apps. There is a client package in debian (mumble) and an app for Android phones (Mumla).
We recommend you use headphones (or half-duplex mode) to avoid any echo.
Notes will be taken at pad.riseup.net. A link to the collaborative document to be posted in chat before meeting.
Comment agenda items here! If you can’t make it to the call but want to put something on the agenda, please feel free to comment in this thread. We’ll get to it if time permits.
@sunil, I’d like to share a couple thoughts from listening to the call this morning. I like the direction of the certificate and DNS discussion and I would be happy to migrate from the current state to that which you envision.
Could these changes also be a path to move FB in the direction of increased protection of users from DNS based monitoring and censorship threats?
As a FB user I want to minimize the exposure of my DNS queries to others - especially the ISP and firms engaged in data collection/surveillance.
As a FB user I want to reduce my exposure to censorship at the DNS level where such censorship may be effected by the ISP or other selected DNS provider.
As a FB owner I want to use FB to provide a secure and private DNS experience for my users.
As a FB owner I want to minimize exposure of user DNS queries in any FB network configuration use case including a local network shared connection.
Of secondary importance to me are these system administration needs:
As an FB user I want to connect to devices on the local network by hostname
As an FB administrator I want to assign hostnames to local network devices
As an FB administrator I want users to know that they are connecting to a local network resource through the use of an internal DNS domain or other mechanism (https://someotherresource.myhomenetwork.net/not-freedombox...)
Last point to clarify - in resolving a local network address through DNS there would not be any impediment to having internal network users and internet users connecting to FB using a host name simultaneously. I’m sure that’s your idea but the technical details were beyond my understanding. Today I use the same hostname internally and externally to connect to FB so long as there is an internet connection, and I understand your vision as not changing that from a user perspective.