i explored writing reduces in flume-ssb-examples

• list channels
  • use so that a client UI can efficiently get a list of channels for auto-complete or browsing
• compute ssb-dns state
  • be able to query dns records by looking up the host & type in an object rather than having to stream and process all ssb-dns messages
• compute git-ssb repos state
  • ideally, be able to get a repo's refs in constant time, and minimal storage overhead. didn't quite get there because of the way the schema and implementation is. however, i saw a way this could be done, with a schema change somewhat maintaining compatibility. (the idea is basically to use a 2p set for the latest value of each ref)

other ideas that could possibly be implemented on this platform:

• stats graphs

  https://celehner.com/ssbc/stats/daily.html https://celehner.com/ssbc/graphs/posts-daily.png currently are generated by cron scripts that take a few minutes to run, while they could be done incrementally instead. but maybe it shouldn't all be in memory like with flumeview-reduce. what might be nice would be to have the long-term data in flumeview-level, and the data about the current time bucket in memory. maybe this would be a layered/pipeline approach - like the "multi-level reduce" which couchdb never got.

• general purpose view for thread/graph things

  get heads for a thread, stream backward from heads, or forwards from a root, etc.. this could allow for a client to do things like streaming replies to a post, without having to buffer and sort them in memory. similarly for loading the state of a git-ssb repo.

• ranking messages

  render a view with messages sorted by some algorithm. like reddit/hn, or facebook news feed. useful for people to see popular content rather than just whatever is most recently published or replied to.

i'm also wondering how we will distribute/install apps that build on ssb+flume. this goes back to the bundled vs global sbot situation [link?].
i guess it will either be:

• view is require'd into scuttlebot and loaded in bin.js with the other core modules
• view is loaded by a thing embedding sbot
• view is loaded as a plugin (pending making that work again)
• we make a distributed computing something

for now, i am keeping unstaged changes to my sbot/bin.js:

+    .use(require('ssb-fulltext'))
+    .use(require('patchfoo'))

that last part is a little off-track, not really about flume. i haven't seen a lot of new sbot apps being made lately though, so maybe it is better to focus on what we have, a discussion platform, and making it accessible and useful. move everything else into the human layer