arthurfranca / is on Nostr

"9bbc2f3aaafd54cdf1893446b9a3f9007e00b449b2e8f069e047592a766803576cba9f5265e6bd2e986a923021c663a8a797d932e568105617d223a1745e7391"

Last Notes

2024-06-22 03:47:57

- reply

https://image.nostr.build/e5e7ab3b3173fbe95495d476cee013333192e2479218cfdfe7b1684adbc30629.gif

2024-06-21 22:02:30

- reply

Time to apply all the theory learned at the University of NIPs. I completed the course with an average grade of 5.7 rounded to 6.

2024-06-21 19:11:48

- reply

Not necessarily gonna pursue low-data usage at the cost of poor ux. It is more like taking advantage of knowing well how nostr works to not ship code that carelessly connect to more relays and asks more events than needed.

2024-06-21 16:31:56

- reply

Agree. When writing a NIP I think of implementation though its hard to spare enough time to actually implement it. Until now the way I wanted to help was just writing NIPs so others that had clients/relays would implement them instead of me.
I did write some relay and client code though I need to inject some caffeine and complete the damn things.

2024-06-21 16:23:43

- reply

I was thinking of lazy loading feed with manual refresh (also lazy loading threads instead of loading all thread notes at once like most clients do). No new live events until user manually refreshes.

2024-06-21 15:30:34

I'm thinking of starting development on a new nostr web client to implement my ideas that always get bashed on the NIPs repo by the nostr gods.
If you are seeing this in the middle of a million notes on a global feed and is interested in an web client that won't suck all your mobile internet plan in a day, follow me for news.. and for rants on nostr NIPs repo scene =]~.
PS: any huebr there?

2024-05-27 16:49:59

- reply

There's a NIP-96 ?w=<image-container-pixel-width> query param that clients should use when requesting images.
We should add something similar for videos

2024-05-24 00:02:21

- reply

"In rare cases, the Bluesky moderation team may need to open your DMs"
This is not a DM feature announcement, it's Group Chat! Chat members: the user, another user and all bluesky moderators!

2024-05-22 16:14:01

- reply

:applause:

2024-05-13 21:19:25

- reply

Kind:1111 to the rescue
https://github.com/nostr-protocol/nips/pull/1233 mind taking a look?

2024-04-26 22:13:27

- reply

People knew of all NIP-17 flaws but merged the PR either way.
There is a PR that doesn't let a hacker read all previous messages and also make it possible to detect a compromised nsec by making the peer inform of device changes while keeping implementation complexity relatively low (though need review and I don't have time yet to implement it for testing) -> https://github.com/nostr-protocol/nips/pull/978

2023-11-14 21:06:31

- reply

I think if there was a separate kind for root notes instead of kind 1 maybe there would be no problem because a root note doesn't reply to anything. For example, long form content is supposed to be a root event so an `a` tag could be used to link to a community.
But reusing `a` tag for NIP-72 clearly was a mistake and should be deprecated in favor of another one letter tag.

2023-09-21 21:22:56

- reply

No one liked the idea https://github.com/nostr-protocol/nips/pull/659

2023-07-14 17:38:31

- reply

Ok but the additional nip17 REQ filters are limited to a subset of the nip17 added fields returned with events and they are namespaced accordingly. That's why it may make sense living in the same NIP.

2023-07-14 14:48:01

- reply

Nice. But could you support NIP-17 filter instead of the custom @lang one?
https://github.com/nostr-protocol/nips/pull/605#issuecomment-1620290873

2023-07-03 00:12:44

- reply

Could you review this NIP pull request related to file storage? https://github.com/nostr-protocol/nips/pull/547

2023-04-02 16:17:49

- reply

No cause then at what relay will you find metadata from said pubkey?

2023-03-29 16:16:49

- reply

This is a test
#[0]