SafeCode

From Hackstrich
Jump to: navigation, search

SafeCode is a software/hardware solution to handle digital safe-calls for independent in-call sex work (and potentially other uses where one wants to let people know they're okay/when they'll be checking in).

Project Status

  • 2015-06: Kitestring has replaced my need for this, calling it cancelled at least for the time being.
  • 2015: kitestring.io is a thing now and works great, so less need for this at least for the time being. Dormantizing.
  • 2013-10-22: More work on the IRC bot interface, now fully works and reports losses of connectivity. Need to implement websocket reconnecting if it disconnects, then do more general QA testing.
  • 2013-07-28: Bunch of work done on the IRC bot interface. Basic functionality now in place, more work to do on bug fixes and extending it.
  • 2013-07-16: Moved codes into config file, implemented distress code, and fixed a couple bugs.
  • 2013-07-13: Implemented matrix scanning for the keypad, now works, which completes firmware functionality-wise.
  • 2013-07-08: More firmware work, now have USB CDC, LEDs. and audio working.
  • 2013-07-06: Completed hardware check-out, only a couple minor issues and one (optional unless debugging) green wire. Started writing firmware.
  • 2013-07-05: Received PCB, assembled, started hardware checkout. So far seems OK, but not done yet.
  • 2013-06-25: Completed mechanical design, PCB submitted to MyRO.
  • 2013-06-23: Got PCB routing mostly done, still need to finish mechanical design.
  • 2013-06-21: Added keepalive functionality between daemon and web service, and fixed lighting to clear error status after 1s. Got most of the BOM and schematic done.
  • 2013-06-20: Initial BOM put together (MCU, LDO, buzzer, LEDs, connectors), just a few transistors and passives left.
  • 2013-06-18: Got a Proto Shield and wired up a piezo element, RGB LED, and cable to connect the Storm 6000 keypad to. Wrote the firmware and the driver module, and it all works! Next step is designing the real hardware.
  • 2013-06-16: Location updates are now authenticated and displayed on the frontend. Frontend also now reconnects automatically if the webservice goes away then comes back. Next step is to make the room daemon reconnect automatically, and start working on the hardware!
  • 2013-06-12: Added functionality to the nav tabs and added a location update form and the first part of the webservice code. Next steps are to make the location used for something, and authenticate updates.
  • 2013-06-09: Refactored web service to use a proper state machine, which only allows valid state transitions. Next steps are to finish implementing end-to-end monitoring and add reconnection attempts to everything.
  • 2013-06-07: Broke out hardware drivers into modules separate from the daemon itself, and wrote a simulator for testing w/o real hardware. Implemented responses from web service to daemon so the box can display the state/last command status. Next step is to clean up the allowed state transitions and finish implementing end-to-end monitoring.
  • 2013-06-05: Added reconnection to the SafeCode Box when the connection is lost.
  • 2013-06-04: Moved all logic into the web service, daemon just sends events (client arriving, check in, check out) now. Decoupled monitoring client screen updates from packets, now timer free-runs in between received packets. Implemented a display of last communication and alerts when communications are lost.
  • 2013-06-03: Got a prototype box up using an Arduino + TouchShield, can now log in to a session successfully. I've kind of got "business logic" spread between the web service and daemon now, next step is to move all of that into the web service, daemon should just be hardware interfacing and keepalive.
  • 2013-06-02: Started writing software. Frontend now loads and connects to the web service, as does the backend daemon. Still have some cleanup/reliability improvements to do, but basic functionality is there (minus hardware interfacing).
  • 2013-06-01: Started thinking about/planning.

SafeCode Box Rev001 Issues

  • Holes don't quite line up with standoffs
  • + pin on ICSP connected to VBUS instead of +3.3v
  • Connector alignment could be better
  • Green component of the LEDs is pretty dim, should look at the C115 (super green) version
  • No hole for sound to go through on the board.

Hardware

  • Small/portable box
  • Rugged design, as it will be thrown in bags/traveled with constantly
  • USB connected/powered
  • Keypad on top to enter data (Storm 6000-21001, telephone-style 12 key + Cancel, Clear, Help, Enter)
  • Lighting to provide feedback for "entry received" and such
  • Beeper for indicating exceeding check-in time without checking in

Software

  • Daemon that runs on the local machine talking to the SafeCode box
  • Web service that runs on an outside server that reports status to others
  • Keepalives between all components to indicate that a connection was broken

Web Service Architecture

  • Sinatra-based daemon
  • Accepts WebSocket connections from the daemon talking to the SafeCode box and monitors to ensure that connection stays open and that keepalives are being received
  • Serves web pages & uses WebSockets to update status in real-time for anyone monitoring
  • Keeps state of:
    • Current geographical location
    • Connectivity to daemon
    • Daemon's connectivity to the SafeCode box
    • Session state
      • Not in session
      • Client arrived, no check-in yet
      • Check-in OK, in session
      • Check-in non-OK, in session
    • Time of next expected check-in (if in session)

Daemon to Web Service Protocol

  • JSON-based
    • Command
      • event - client_arrived, check_in, check_out
      • code - string
      • length - numeric (only implemented for check_in)
      • distress - true/false (only implemented for check_in)
    • Response
      • status - accepted, error, distress

Photos