log.ryanatkn.com

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:

@ntnsndr@social.coop (Mastodon): WIth ntnsndr.in/ImplicitFeudalism 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?

@ryanatkn@hci.social (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: hci.social/@ryanatkn/109770994846184255

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. Felt.social plans to be a platform co-op operator providing infra.

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

link

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.

link

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

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: github.com/feltjs/felt-server/pull/663