fxbox/rfc

Discussion about design decisions

rfc's Issues

Decentralizing ChannelType, Value, Type

Problem statement

The definitions of ChannelType, Value, Type are currently centralized in the Taxonomy. This places a heavy maintenance burden on that repo and complicates extensibility.

How can we decentralize them?

Proposals

1. @mcav's proposal: fxbox/deprecated-taxonomy#63 (should be turned into a Pull Request in this repo)
2. @Yoric's proposal: #9

Managing errors

For reference, here is the current code: https://github.com/fxbox/foxbox/blob/998b6e0e1e1fd3cba3b711783eaa7000c2f66a0d/src/adapters/mod.rs#L61-L69

Basically we unwrap on any error. Some adapters are not returning an Error for some errors because of this.

The end-user can't see panics because his only access is through a web browser. So we need another way to log the error instead and let the user act on it (especially we might need to be able to restart the foxbox from the browser -- but this is for another issue, I think).

First tentative solution:

• init methods return a taxonomied error enum.
• this error would show error levels: eg: Warn, Fatal, Critical.
• this error would contain the cause. The cause should be a real error that implements Display/Debug/Error.
• the box would log the result somewhere the user can look at (but this can be in a separate RFC). For now we could simply log warnings and panic at fatal and critical errors.

Second tentative solution:

• we replace env_logger with a logger that would keep the logs in a central place to display it through a we bbrowser
• the adapters init function directly uses this to log what needs to be logged
• the adapters init function returns a Error only for Critical errors.

RFC: This RFC repo/process is unnecessary and should be discontinued.

We don't need a decoupled RFC repository. Few people "watch" this repository for changes (2, as of this writing), making it necessary to broadcast RFCs elsewhere. I don't see how this is any better, or as good as, posting GitHub issues in appropriate repositories.

Box discovery

We need to work out how the client discovers the Box.

Terminology:
Box: The box being developed in Project Link
QR: Use a QR-code on a sticker on the Box to tell the client which URL connect to
mDNS: The Box uses mDNS to tell the client its IP address and/or its full URL
HSS: The client checks the TLS certificate against the fingerprint in the trusted URL string
plex: A public DNS zone is used to announce the Box's local IP address
LE: LetsEncrypt is used to register/renew a TLS certificate for the public plex-like domain name
NUPNP: A server on which the Box can publish its local IP address so that the client can discover it
Cordova: A tool for packaging web apps a native apps, with plugins for adding custom functionality that is usually not available in browsers.
client: A smartphone, tablet, laptop, or TV.

Assumptions:

• QR-codes work well on smartphones and tablets, but not on laptops and TVs
• mDNS is supported by major browsers on iOS, OSX and Linux, but not (yet) on Android and Windows
• we prefer a secure solution
• we prefer a local solution (not leaking user data to the cloud)
• we prefer a solution that uses standard mobile browsers (and standard mobile QR-code readers)

Managing configuration

Currently we manage configuration using a ConfigService that takes its values either from the command line and/or a configuration file.

But we'll want to expose configurations to the user through a web interface. Moreover some configuration might be dynamic (eg: door lock's codes, which luminosities mean day and night). So it would be better to expose them through the Getter/Setter (or whatever we come up with the decentralised taxonomy) with a special type: Config (a normal Getter/Setter could have a type User). Maybe the type could be a Tag instead.

Should we support basic types for ChannelKinds?

For example, I need a String getter/setter to get/set the camera_name, username, and password, and it seems kind of lame that I need to create Extensions to do this.

Perhaps we can have a simple extension kind that is just a JSON object?
Why do we need a vendor for custom kinds and not for OnOff?

Restricting remote access compared to network-local access (or not).

The Box will be accessible through the local network (when you're at home, or in the building where the Box is installed), as well as remotely (when you are away from home / not in the building where the Box is installed).

When connecting to the Box over the local network, all functionality (except maybe factory reset, which could be a physical button on the Box), would be accessible to users with sufficient permissions (there is always at least one admin user, who has all permissions).

Remote access can be activated or disactivated. Whether it should be activated automatically during first-use (opt-out), or should only be activated if the user wants it to (opt-in) is a separate topic of discussion, we're not discussing that here.

The question here is: when remote access is activated, and a user is connected remotely (via the Bridge), should the accessible functionality be:

1. always equal to the functionality to which that user has access when connected locally, inside the home/building?

Or:

2. be a subset of that.