my avatar image

  • home
  • source
  • Apr 17 2023

    Mar 28 2023

    Mar 17 2023

    • added the initial proof-of-concept for, an ear training game and tools for programming music and audio, features a configurable trainer and a piano with MIDI support (source, pull #1)

    Mar 1 2023

    Feb 25 2023

    • changed dealt ( to have its stages and entities be data-driven, opening up some interesting opportunities (#62)

    Feb 22 2023

    Feb 20 2023

    Feb 5 2023

    Feb 1 2023

    Jan 28 2023

    • revised and tooted about my second blog post, "Modeling virtual social spaces: in this house we post cat pics on Saturday", with more on Mastodon: (Mastodon): WIth in mind, I'm curious whether there is any possibility of checking the power of Control? Is there a way in which that could be non-absolute? (Mastodon): Yeah! Here's how we're thinking about it right now with Felt. Still ratcheting up the ladder to climb out of the feudal hole.

      Control is held at the group/org/community level (Felt names these "hubs" now) by actors. In the default hub template the creator gets the all-powerful "steward" role, but the hub itself has an actor, and control is transferable/sharable. The hub actor's actions are controllable by automated/assisted/direct processes. Other group actors could be involved.

      to clarify, "steward" is just the name for a role in the default hub template and a convenient way to reference the idea, they can be constrained with fine-grained permissions like any other customizable role - this contrasts with Slack (no customizable roles) and Discord (coarse-grained permissions)

      given this API you could design a set of roles that split powers, separating/balancing concerns

      hub templates make it easy to share pre-fab designs with the initial roles/permissions/etc

      In our implementation, actors are assigned roles which have permissions. You helped me realize that by splitting permissions among roles we could support non-absolute power with this:

      An all-powerful group actor's actions could result from collective governance processes

      or, I think we can support designing systems with structural checks and balances through permission assignment, so any actors could have mutually co-checking subsets of permissions in a hub

      That's the first-order UX prioritized by end users. This second part is ignorable by most people most of the time, but for the governance enthusiast:

      Hubs are hosted on infrastructure controlled by "operator" actors. These have the power to pull the plug, and may technically have hub control bypassing stewards, like modifying a database.

      Maybe there's instance/server/etc levels between infra and hub, but that's an impl detail. Felt has instances controlled by "admins".

      The operator actor could be co-ops/nonprofits/other orgs, or as you've written about, bl0ckchains or similar. Bchain enthusiasm makes sense here b/c the operator won't pull the plug or modify the db barring acts of God. plans to be a platform co-op operator providing infra.

      btw I love this so much, Boba Board ( has leaned into *explicit* feudalism for their fandom communities, owning it right in the brand! "Be the Monarch of Your Own Realm!"


    • wrote a long comment about sveltešŸsnakešŸsports (source) on aliensite:

      Oh hey I'm the Svelte Snake Sports author, thanks for the mention. A few things if anyone tries to learn from the the code:

      • The code is not refined at all. Some parts are pretty clean, but at the top level where the games are implemented, it's kind of a mess. If I had more time/energy I'd refactor a lot of things and figure out better interfaces. The goal was to support highly varying kinds of games, and I succeeded at getting my designs to work, but I wouldn't point beginners at the codebase to learn from unless they were very motivated and understood how weird some of it is.
      • There's some experimentation with component instances exporting their objects for external access as an alternative to plain modules or stores -- in particular $lib/SnakeGame.svelte. That's why it has <svelte:options accessors /> at the top. I wanted to be able to use Svelte's sweet component-level reactivity. The pattern works but it makes initialization much harder. I'm dubious about its value because of that.
      • The REPL version is broken because some dependencies had major version bumps and the REPL is just importing from unpkg without versions. I was thinking I should bundle everything into a single script -- I have a fork of the repo for publishing to NPM for the REPL because it fails with types in the Svelte files. Pretty hacky all around. I thought the REPL version was important for the project to be more approachable but it's been a headache, mostly because of my own mistakes.
      • I like the AI generated images (it took a while to get cute-looking snakes) but I probably won't do it in the future for this kind of project, I'd draw/code my own or pay artists instead.

      It was a lot of fun to make though! I was needing a break from more serious work.

      Just tried it on mobile and it seems the tap location calculations are off if you're scrolled on the page, I know what I did wrong and will probably fix soon. It's also scaling weirdly when I scroll, darn.

      Also if you click "show settings" at the bottom you can change the map size and some other things. Lots of potential but I ran out of steam. I have a different non-snake action game that I'll probably work on instead when I have that itch to scratch. It has some gameplay but is unfinished/unpolished and it's not communicated well.


    Jan 24 2023

    • renamed this project's main building block from Bulletin to Digest, seems friendlier and better for puns (commit)

    Jan 23 2023

    • moved most of our projects on GitHub from @feltcoop to @feltjs, which will be a nonprofit, tightening @feltcoop's scope to be a platform operator at (still with the goal to be a platform co-op), and making @feltjs and its repos a community project more explicitly

    Jan 22 2023

    • posted the first draft of my second blog post, Modeling virtual social spaces: in this house we post cat pics on Saturday
    • posted my Svelte 4 wishlist to a Reddit thread in /r/sveltejs:

      • an opt-in way to better scale components - this has been mentioned by the team. I'd love to construct Svelte components from data without the compiler! I have no idea how feasible that is but it might be enabled by this feature. This could be a path for end users to "author" Svelte components without sandboxing or the compiler (with limits, but the way I do this today with an AST+component is much worse).
      • iterator support for #each or a similar construct (#iterate? it'd be nice to render sets/maps/etc without waste)
      • my two favorite RFCs are inline components and directive forwarding
      • shorthand style properties style:--some_css_var (without the ={var} part - I don't care about using kebab-case specifically for CSS vars, I think this wasn't implemented because of that, but +1 for snake_case CSS vars)
      • whitespace handling (inherited from HTML, so very unlikely to change I think), sometimes significant whitespace causes problems, and the fix makes the code much less readable, it's one of the only things I miss from JSX
      • I don't have specific suggestions but slots have some limitations that would be cool to see lifted
      • the syntax to pass CSS vars directly to components breaks things like :last-child and other selectors, I think it may be an intractable problem tho

    Jan 17 2023

    • added the Board view to Felt - it's like a chat room but upside-down, so the input is at the top and content flows downward, replies are nested, and the newest posts and replies appear at the top:

      a screenshot of the board

    Jan 11 2023

    Jan 8 2023

    Jan 2 2023

    Jan 1 2023

    my avatar image