2019-01-30-weekly.md

sunrise choir - 30-1-19

attendees

• mik(ey)
• pie(t)
• mat(t)

Agenda

• checkins
• piet update
  • had very disrupted week last week. Little progress.
  • newsletter (anything to add?)
  • latest schema
  • https://github.com/sunrise-choir/ssb-flumeview-sql/projects/1
  • goals for scuttlecamp (shit we'd like to show off)
  • posting about stuff on the butts (AGPL)
  • ssb-about. Does Matt use the socialValue and latestValue?
  • does patchwork care about all mentions, or just mentions of your key?
  • discuss native bindings vs a server based approach like xray. Not for now, but for the future.
• checkouts

piet update

• pie: newsletter: anything to add?
• pie: latest database schema
  • tables:
    • migrations
    • messages
    • authors
    • keys
    • contacts
    • about
    • mentions
    • links
    • branches
    • (blobs)
  • have created raw tables which use integer ids instead of hash strings, then use sql views which join the raw tables underneath the hood and you can query as if they were the actual table
• pie: kan ban board: https://github.com/sunrise-choir/ssb-flumeview-sql/projects/1
  • great to keep track of progress
• pie: goals for scuttlecamp: shit we'd like to show off

  • what is a sweet mvp goal to achieve for camp?

  • mat: we talked about last week a pairing session to make our own sbot, proof-of-concept Patchwork that uses this sbot

  • mat: def want some sql stuff running

  • pie: i'd really like if we could make the main feed coming from a sql query, plus the latest mentions. but about seems harder

  • mat: needs to query more data than it uses, then filter down

    • the other option is we think about how to do this in sql
    • the old way is that we use a reducer in real-time, then when you query you'd get what each person said about any particular thing
    • what's the latest thing they've said about it is most important
    • pie: will be like contacts, update each entry with latest
    • mat: was trying to do less flume, wanted to query a subset, wasn't a good primitive
    • pie: probably a good candidate for pairing, mat you have the context in your head, you know the questions in your mind
    • mat: my dream at scamp would be to have multiple clients using our sbot, even if they don't work amazingly, just show what could be possible
    • mat: make a really shitty plugin for flume that was read-only, so you could run another sbot on top of lessbot
      • all you need to get patchbay running is to swap out flumelog-offset with flumelog-follower
      • to run an sbot on top of another sbot, so the publish falls back to the primary sbot, the reading uses the follower sbot

  • mik: the demo doesn't need to be friendly, it just needs to communicate the intention behind our work

    • start the lessbot daemon, start a forked Patchwork, start a forked Patchbay, they both have their own plugins & indexes which don't conflict, following the same flumedb & lessbot

  • what are the slowest and hardest queries, how can we do those with sql?

    • mat: participating
    • mik: could be really good for newsletter and demo, show off how to do a query from the old way to the new sql way
      • walkthrough a specific query, describe in detail how it used to be done, describe in detail how its done using sql and the relevant tables, rinse and repeat
        • what are the queries that are the building blocks of the clients?
        • how have we constructed a new sql flumeview to allow us to do this queries better?

  • scuttlecamp / newsletter comms:

    • 3 project focuses to communicate:
      1. rusty sql flumeview: how we are enabling core queries to be done better
      2. consensus-free scuttlestack: how to run multiple clients, each with their own plugins & flumeviews without any possible conflicts
      3. born-again Scuttlebutt: how to evolve the Scuttlebutt project for the next generation of contributors
    • format: present these concepts, don't even need a working demo

  • mik: the next newsletter can just be the story so far.

    • work so far, directly quoting dev diaries:
      • mik's original post to introduce the project, context on why this project was created
      • pie's rusty bindings, private box
      • alj's spec work (quote his ending post)
      • pie's rusty flume & sql flumeview
      • teasers of the upcoming work, mat joining
    • images
      • snapshot of mik's original post
      • snapshot of alj's spec website
      • all the messy whiteboard photos
      • pie's sql schema

  • mik: write newletter as .md file in https://github.com/sunrise-choir/meta in newsletters/ as 2019-01.md, put images in newsletters/images/

    • also post on medium
    • also post to the butts.
• ssb-about. Does Matt use the socialValue and latestValue?
  • socialValue is used for names, avatars
  • latestValue is only used for gatherings
  • all this is hacky, we need better revisions like ssb-revisions
    • keen to collaborate with regular about this
    • probably want funding from handshake council on this
    • related to other external contract work i'm doing
• does patchwork care about all mentions, or just mentions of your key?
  • mat: yes, uses both. Used by search, also can right click on an author, find link refs.
• discuss native bindings vs a server based approach like xray. Not for now, but for the future.
  • pie: don't really want to talk about it now, but want to point at it as a potential approach for the future, if we want to scale bindings (especially async)
  • mat: would love to move Patchwork to be based entirely on that structure, i'm pretty over JavaScript to be honest, whenever i write Rust i think it just works better, fuck yeah Rust
  • pie: still feel like i'm getting sweet gains, runs first time after compiling, yay