Lightnews — Scholar-powered news

dan @danabra.mov · 10m

i haven’t found something like that.

the protobuf emitter has a specific Extern type for it: typespec.io/docs/emitter...

maybe that’s fine though feels a bit inelegant.

Data types

Data types exported by @typespec/protobuf

typespec.io

dan @danabra.mov · 24m

i was actually pessimistic that it would happen at all. since there’s been increasing legal red tape at meta over time as the company grew. so i’m glad it’s happening. i’m not sure how this will impact governance if at all, and that remains to be seen. i’m a big fan of letting the team do its job

4

dan @danabra.mov · 26m

re: why now, there’s been desire on the team for a foundation since maybe around 2017 but the project *was* run by one company then. by now, it’s not — there’s nontrivial investment by other companies, and has been for several years. so i guess the structure is finally catching up with reality

1 1 4

dan @danabra.mov · 29m

sure! also didn’t mean it as an attack — i just think it’s interesting context because lots of companies don’t treat their open source projects that way

1 5

dan @danabra.mov · 31m

the main reason react got open sourced at all, and then stayed maintained (not just “throw code over the wall” style) is because everybody working on it knew they don’t want to reinvent it from scratch at their next job

22

dan @danabra.mov · 36m

in my opinion this ended up being a great thing for react. if you chase “adoption” as a primary metric in your open source project, you’ll make different choices than if you just want the project to meet its use cases and be useful to other people

dan @danabra.mov · 40m

i worked on react at meta for eight years, and there was literally never a moment when the management would ask what we’re doing to increase “dominance” or “market share”.

if anything, the pressure was always slightly nudged towards internal use cases, and the team successfully pushed back on that

2 2 35

dan @danabra.mov · 40m

i worked on react at meta for eight years, and there was literally never a moment when the management would ask what we’re doing to increase “dominance” or “market share”.

if anything, the pressure was always slightly nudged towards internal use cases, and the team successfully pushed back on that

1 1 14

Reposted by dan

🍅🥔🫐🌽 hoopy frood 🌶️ 🥑🍫🌵 @huwupy.kawaii.social · 56m

Might make an AppView for fun what’s the best repo to fork these days

1 1 18

Reposted by dan

natalie @natalie.sh · 1h

42k scrobbles 😵

2 2 27

dan @danabra.mov · 1h

ayyy @ricky.fm’s getting a second chance! i’ll watch though it’ll be late

Ricky @ricky.fm · 1h

Part 2 is on the schedule, I’m just going to start the demo over and finish the talk from there

10

dan @danabra.mov · 1h

hmm! interesting though maybe a bit too implicit? is this for uncontrolled fields?

dan @danabra.mov · 4h

yeah, no magic. if you do include it, it will re-attach

1 1

dan @danabra.mov · 4h

yeah it's a bit subtle — it doesn't cause an Effect to re-run *because* it is not a dependency, and it's not a dependency because those are the rules :)

1 1

dan @danabra.mov · 4h

i'm referring to this problem (which Astro/client integrations have, but RSC don't)

dan @danabra.mov · 17h

i don't even think of it as shared state per se. it's as simple as

<ReactParent>
<AstroThing>
<ReactChild>

no longer being a tree in which ReactParent is an ancestor of ReactChild. from react perspective this is absurd

1

dan @danabra.mov · 4h

posted some thoughts on "external lexicons" workflow for typelex. tangled.org/@danabra.mov...

this would require a CLI that generates stubs based on a list of external lexicons. this makes me think it might make sense to adopt a convention like lexicons.json from jsr.io/@lpm/cli

cc @tom.sherman.is

1 10

dan @danabra.mov · 5h

maybe worth squeezing padding a bit more? bumps at the edges

2 22

dan @danabra.mov · 5h

but if you multiply it by π it should come out about right

Always Multiply Your Estimates by π - 推酷

Always Multiply Your Estimates by π

web.archive.org

2 17

dan @danabra.mov · 5h

yay! “three hours” was bait tbh

Tangled @tangled.org · 5h

*ahem*
tangled.org/@danabra.mov...

that was not a three hour change btw :)

1 33

dan @danabra.mov · 6h

yeah. that’s pretty much how it works internally.

dan @danabra.mov · 6h

it wouldn’t be a “defederated instance”. blacksky, even when running its own API server, would run on the same network as everyone else.

it’s not a separate disconnected world like in mastodon, it’s just a different distributor. read rudy’s thread, it actually explains how this works!

1

dan @danabra.mov · 6h

@bnewbold.net @pfrazee.com search is busted!

1 19

Reposted by dan

jenn schiffer 🕷️🕯️ @jennschiffer.com · 19h

this thread is the best communication for me so far on how all of the parts of the protocol and clients work together (and sometimes against each other)

Rudy wants revolution. @rude1.blacksky.team · 20h

I hear and see your concerns. Over the weekend, a couple users hosted on Blacksky's PDS were banned from the Bluesky app and thus the Bluesky API servers. This was a weakness of our system I've been aware of and hoped we had more time to address before any kind of public incident. 1/11

2 19 84

dan @danabra.mov · 15h

ah! you mean claude

40

dan @danabra.mov · 15h

not gonna lie, i’ve been getting lazier and lazier with prompting in part because it’s just fun to see what it does and i get a bit of a kick out of seeing it figure things out from minimal info. i tell myself i’m building an intuition for what it can infer but it’s also just addictive

1 3

dan @danabra.mov · 15h

basically i think the Bluesky client app itself needs to include “enough” tooling to protect yourself from Bluesky, with no need to evaluate and trust third party tools. should be part of the package

1 5 49