Den trenger nok «atproto»-scopet. Profil-recordet mener jeg er offentlig tilgjengelig så må ikke ha scope på den med mindre roomy skal redigere infoen.

Roomy.chat ber kanskje om litt mange rettigheter bare for å logge meg inn med Bluesky/ATProto-kontoen min. Tror det skal gå an å angi mer finkornede scopes.

Ref:

atproto.com/specs/oauth#...

github.com/bluesky-soci...

Hei👋. Definitivt interessant å bli kjent med andre som er interessert i og kanskje også bygger ting på ATProto.

Har troen på protokollen for å skape plattformer som løsriver oss fra amerikansk tech-hegemoni og der dataeierskap fundamentalt flyttes til brukerne og tilrettelegger for åpne data.

Visuelt veldig pent fortalt film med fine praktiske effekter. Det skinner som vanlig igjennom at del Toro har stor kjærlighet for monstrene sine. Men synes kanskje filmen bærer litt preg av å være laget for Netflix-generasjonen som skal surfe mobilen samtidig som de ser film.

Interesting. So instead of specifying an object type inside the record definition, you'd specify a ref type to a common fragment defining the object? Will have to try it out.

But duplicating the object definitions might be more flexible for evolving record type and view type independently.

If this is the case I'm thinking lifting as many properties from the record types into the view type as possible is good to get proper typing in auto-generated clients, etc.

There might be better ways to handle this, but I think it works well enough. It impacts build performance a tiny bit, but NVMe drives and modern computers are fast!

To handle references to other record types I needed to look at the NSID defined for other structs which isn't possible in Rust proc macros directly as they can only access the AST of whatever struct or type you pass into the macro. Ended up scanning all source files looking for struct and its nsid.

It also checks if you are using the correct lexicon type constraints on the correct type of fields. For example if you add "max_graphemes = 10" on a u32 field rust-analyzer will output:

Invalid constraint on field 'limit': 'maxGraphemes' constraint is not valid for type 'integer'.

*Emma Stone. Autokorrektur er styrete.

Interesting. Thanks for sharing. Self-hosting absolutely seems the way to go for now. I do think Bluesky as a company could reduce barrier to development by hosting a test network. But sans that providing a complete local environment via docker compose or similar one command setups would be nice.

Nettlesere er hyggelige nok til å oversette fra punycode tilbake unicode så du får den særnorske bosktaven som forventet. Men ikke så mange webapplikasjoner gjør det. Typisk av anglofonske utviklere å ikke tenke på slik.

en.wikipedia.org/wiki/Interna...

Serverne brukt til å slå opp domenenavn til ip-addresser støtter i utgangspunktet bare ASCII (a til z)-bokstaver og støtter ikke særbokstaver. Så man har en standard, punycode, for å representere unicode som ascii. Teknisk sett er egentlig domenet ditt: xn--mrkeloftet-0cb.no i datasystemer.

Ah yes. Purchasing one pastry a week is overspending. But we can’t figure out why people aren’t having kids anymore. Such a mystery!