Comment by hugs

Comment by hugs a day ago

thanks. also, fwiw, i'm also a very a happy AT user (@hugs.bsky.social) besides also being a happy nostr user.

i appreciate bsky's focus on user ux and community building and look forward to seeing more sharing of ideas between nostr and AT.

edit to add: to nerd-snipe my brain into wanting to make stuff with AT (or any future protocol) is to focus on a quick-start or tutorial showing the absolute minimal client to send one message.

once i can do that... i'm ready to learn all the rest of the vocabulary and server-side stuff, but not until i can send one simple message from a barely functional minimal client.

danabramov a day ago

Would it be ok to use a library or is the requirement to keep it to raw primitives like curl?

Reply View 4 replies

hugs a day ago

i like seeing a bit of the raw, low-level protocol first. a few curl examples are perfect for understanding what’s really happening under the hood. once i get that, i'm happy to use a library to handle all the edge cases.
but starting with a library tutorial makes me wonder how many stacks of turtles are being hidden. if i can see the turtles upfront, i'll appreciate what the library does for me -- and i'll have a better sense of how to debug when things break.

Reply View | 2 replies
- danabramov a day ago
  
  Absolutely. I think it’s a great constraint actually. I have a few other pieces in the backlog but I’ll keep this one in mind.
  This isn’t quite what you want but should illuminate at least the “fetch on demand” part in detail: https://overreacted.io/where-its-at/
  
  Reply View | 1 reply
  
  hugs a day ago
  
  yeah, that looks like a good base for a simplified remix. thanks!
  
  Reply View | 0 replies
evbogue a day ago

everything we need to authenticate the msg should exist in the msg. sig => timestamp, hash

Reply View | 0 replies