Solidbox
Pending tasks in developing Solidbox.
Sensing
We want the box to detect and report how it is used. Similar to an intrusion detection system, but for regular use rather than abuse.
Detection will likely be done by pattern-matching logfiles, and reporting will be done by storing semantic web "triplets" in a local RDF store. So we need to identify what to look for, and figure out how to express the events we detect as semantic web triplets.
Install user-facing services and corresponding clients (e.g. ejabberd and gajim, mpd and ario, etc.) on your laptop or another computer, play with them, locate which log messages the services generate where for interesting high-level interactions, document the exact log strings that we want to detect, and try express a regex (Regular Expression) for each.
Maybe service configuration need to be adjusted to log all the activities we want to monitor (because normally sysadmins are more interested in abuse). When config tweaking is needed, document the minimal possible tweak for each change we need.
Detect activities with Sagan (or logdata-anomaly-miner or Prelude LML?)elMor3no
- New Jabber account created
- Succesful Jabber login
- Update of Jabber roster
- Jabber friendship request accepted
- Chat activity with Ejabberd (or Prosody or Matrix Synapse or Biboumi?)
- Music selections with MPD (and MPD Sima)
- Detect hardware features (with lshw?)
- Audio device
- Detect network features
- Network access (IP number other than loopback)
- Gateway
- Nearby Zeroconf services?
- misc system metrics? (using pkg:victoria-metrics - efficient Prometheus-compatible time-series database)
Collecting
We want the box to collect centrally all facts about interesting usage.
Reporting is done by storing semantic web "triplets" into a local RDF store.
We need to figure out how to express our activity facts as semantic web triplets.
Install and play with existing harvesting tools, and share e.g. to mailinglist how useful they seem to be.
For each interesting sensed activity, try express that using existing ontologies, or locally added (phantom-)ontologies.
- Evaluate relevancy and efficiency of existing semantic harvesting tools
- Locate (or invent) ontology to express all facts relevant to us
Reasoning
We quite likely want to refine our collected knowledge base - to "shake the tree" or "squeeze" information out. Reasoning tools exist which can reveal implied knowledge, which can then be stored back into the knowledge base as explicit facts for later quick querying.
For quick introduction to the topic (or one flavor of the topic: OWL2 reasoning), try read this blog post.
Try install some of the reasoning engines, play with them, and try come up with example implied knowledge and concrete ways to have a reasoning engine re-express that as explicit facts.
- Test and decide on reasoning engine(s) to use
- Resolve actions at idle times
- Ownership of box: First user to ever login
- Welcome message: After each login to an account until acknowledged
- Enable Website: For each network access (limited to that - i.e. not wildcard)
- Disable Website: For each network access no longer available
- Write action suggestors
- console using "write"
- console using /etc/motd
- Maybe Dbus (to support Cockpit?)
Storage
Sensed and reasoned facts are stored in a triple-store (or maybe a quad-store).
- Decide on triple-store/quad-store to use
AtteanX::Endpoint (maybe as SPARQL 1.1 frontend for another storage backend)
tracker (maybe only for desktop asset tracking, syncing with another storage backend)
zeitgeist (maybe only for desktop activity tracking, syncing with another storage backend)
- Store activity log semantically with Zeitgeist (or Virtuoso?)
- Store storage metadata semantically with Tracker (or Pinot + Virtuoso?)
- Store actions semantically with Virtuoso (or Zeitgeist?)
- Find and package (or write?) action bot
- Write action suggestors
- (with Dbus interface to later support Cockpit?) + Jabber + SMS?
- Write action executor
- (with Dbus interface to later support Cockpit?)
- Setup Boxer images
- + for recommended devices (Olimex OSHW boxes) + for testing (i686 QEMU)
Data projects
All data must be 5-star Linked Open Data (LOD) (with obvious exception of only being as open as owner permits).
A good place to browse inter-linked ontologies for LOD is <https://lov.linkeddata.es/dataset/lov/>.
- Design ontology covering Boxer
- Package relationships and use (very likely ADMS.SW)
- Package subjective relationships and "rating" (covering debtags and popcon)
- System "personality" ("introvert" hides itself most possible, "extravert" promotes itself)
- System "states" (pristine/activated, offline/localnet/internet-connected, broken/limping/all-systems-go)
- Dialogue (covering debconf)
- Decide on default/offered data publishing format(s)
Maybe LOUD?
Code projects
- Public-facing WebID service
- Visualize WebID data as web homepage (in html5 preferrably with RDFa).
Maybe use Jekyll-RDF
- Harvesters (via web proxy) for legacy social media services
- Probably needs setting up a "man-in-the-middle" SOCKS proxy
- Bridge for PIM tools using imip-agent
- Import photos to CardDAV from RDF (i.e. FOAF profiles)
- Export photos to RDF from Facebook (passive sniffing)
Export photos to RDF from ?ActivityPub (i.e. modern fediverse services like Mastodon)
- Extract travel data from CalDAV stored with F-droid App
- Visualize travel data
Packaging
Setup package maintenance page at https://wiki.debian.org/
- Inspiration:
- Package and maintain Debian packages of Solid-related code projects
- simple-rdf
- relevant ontologies
?MusicBrainz dataset
- Triple/quad-stores (as alternative to Virtuoso)
atomic server (only as auxiliary service: supports only a subset of RDF)
- Reasoning engines
- Wrappers for reasoning engines
owlcpp - OWL2 reasoning for FaCT++ with Python wrapper
Boxing
- Build images
- Test images
- Define what it means to "work" - i.e. what exactly to test
- Document manual test routines
- Setup testsuite for parts that can be automated
- Setup service continuously running testsuite
- Test on virtualized environment
- Test on supported device(s)
Communication
Our target for the box are non-technical users. Our development should attract skilled people.
Read user-facing website. If it something doesn't make sense even to you, or seems confusing or complex or irrelevant for a non-technical person, then discuss that at either our mailinglist or on irc, and (when you understand it yourself) try propose better ways to express it.
Read our wiki pages. If it something doesn't make sense even to you, or seems confusing or complex or irrelevant for relevant skilled persons, then discuss that at either our mailinglist or on irc, and (when you understand it yourself) try propose better ways to express it.
If you have special skills useful for developing Solidbox, then please do dive in!
Example: Skills in human languages other than english is helpful for translation of website and (when developed) user-facing chat dialogues.
Example: Skills in user interaction design is helpful for helping develop sensing and user-facing chat dialogues.
- Decide on chat bot dialogs
Improve user-facing website https://solidbox.org/
- Describe getting and personalizing a box
- Describe common usage
- Describe security and trust
- Design artwork
- Design experience
- Setup "I run a Solidbox" fan/broker service
- Solid (i.e. FOAF) linkage?
- Preferably using an RDF-based templating system
Translate https://salsa.debian.org/solidbox-team/website/blob/master/locale/content.pot
Community
- Mailinglist
- Setup mailinglist-service on a (non-solid!) box
- User list
- Developer list
- Setup mailinglist-service on a (non-solid!) box