There is a #NIP94 , why add a #NIP71 now ?
https://github.com/nostr-protocol/nips/blob/master/94.md
https://github.com/nostr-protocol/nips/blob/master/71.md
#asknostr #nostrdev #nostr
Maybe this event has an old enough created_at field ?
These days i am thinking about that we can't believe the field created_at in the nostr system. Due to many relay don't check the created_at field. Usually we can create a past event. But in many scene, for example a todo system, the created_field is very important.
I don't remember, but I saw nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp's old metadata (old ln address) in many relays from nostrs.watch . I made a script to update them to the new one but many rejected the new event. :(
You means you broadcast this event to other relay and sometimes they reject it?
If anyone wants to help me improve the conversion between wikitext and NIP-54 markdown please help: https://git.fiatjaf.com/wiki-importer
I'm currently using Pandoc with a custom Lua script for formatting the links and removing the images (yeah, I'm not sure how to properly grab the images, if anyone want to help with these that will also be great), but some things are not working well, like footnotes.
It seems that wikitext is a bit like markdown.
for now whick clients haven't implemented outbox?
You can try to config a proxy relay, the config also a nice solution for nostr.
nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h can we make sure that theforest retains all notes that aren't kind01 or deletes?
How is that being managed, now that we're writing more articles and git proposals and other technical/topic notes?
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft is there a relay aggregating Wiki notes, as a backup?
How do sov and eden look, nostr:npub1gnwpctdec0aa00hfy4lvadftu08ccs9677mr73h9ddv2zvw8fu9smmerrq and nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj ? Are you accepting Wiki notes and how long will they be stored?
run your relays and own your data
这房子现在值多少钱 涨幅抵得上利息吗
1 可以在手机客户端打开这个网页恢复
https://heguro.github.io/nostr-following-list-util/
2 可以尝试在客户端中按照以下步骤恢复
a 长按联系人数量
b 松开后选择合适的记录即可恢复
很多次了 要想办法优化一下这里
有一个找回功能
长按你的用户联系人数量那里 过一会会弹出历史列表 选择合适的数字的联系人
Question...
Should ALL #nostr clients give the user the option to change the relay they post/publish at?
The question came up while I was adding that UI for nostr:npub17jl3ldd6305rnacvwvchx03snauqsg4nz8mruq0emj9thdpglr2sst825x , would it be fine not to have that option? They can go to other clients to change it.
The example client here would not let the user change their relays, but it would get their saved relays and push it to them, as well as push it to the relays that they clients pushes for.
I'm thinking that's not a good mentality to go with, but I'm also trying to consider having a simple flavor. Thoughts?
#asknostr #nostrdesign
Yes, users should confiv their own relays.
慢慢看看吧 我心里也不太踏实
国人我都不敢关注 你们经常讨论政治
不是说你们不好 是我主动回避一下而已
Nostrmo version 2.6.0 has release.
Thanks Karnage, many change in this version was came from his feedback.
Change list:
Change UI.
Add Zap Split support.
Add NWC support.
Add new user welcome page.
Add Blossom upload function.
Fix many bugs.
This version upgrade not include IOS and MACOS version, due to my Macbook can not use anymore. The IOS and MACOS upgrade may come in next month.
You can download from app store or download it from:
https://github.com/haorendashu/nostrmo_faq?tab=readme-ov-file#download
#nostrmo
But the Blossom only a spec. Maybe some implements will add compress function to handle images.
It claims that server shouldn't change the file content.
https://github.com/hzrd149/blossom/blob/master/buds/bud-01.md#put-upload---upload-blob
cloudflare 这种免费配额我感觉还好，他们应该不会拒绝，毕竟有可能转化为付费用户
