Profile: 738ea36e...
Isn't store distribution the main reason? Couldn't compiling a version-pinning browser together with an embedded default PWA link as a native be a solution?
What are your thoughts about PWA version pinning browsers (as a solution for the "malicious update" risk compared to native apps)?
Ultimately everyone could compile a VPB (version-pinning browser) with a default link to their PWA and upload to the app store🤔
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
Agreed. Amazing client!
Dynamic thread data on nostr:npub1j3t00t9hv042ktszhk8xpnchma60x5kz4etemnslrhf9e9wavywqf94gll (like thread summary, authors, total messages, and so forth) is now captured in a long-form content event (NIP-23) and linked from the thread event.
- It's displaying beautifully on Amethyst (thanks nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z )
- Long-form content on habla.news is visually appealing; this inspires me to enrich it with all thread's AI-generated message summaries.
- I aim to endorse social clients integrating nip-23 references in archive threads. If you're building a client, please consider this feature! :)
- Should I broaden the scope and develop a general "mailing-list to nostr" app? Are the relays up for it? 😉
nostr:note12fp5dywscafcnfceupmh8hvgswcyfv65ym536pckvs4rfm56j9ysmwl6ch
Testing highlighter on a summary of a thread from the lightning mailing list
Yep, I used both the a tag and nip-19 naddr code.
Seems like Amethyst doesn't correctly show the latest update (last "created_at") and habla.news does nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
That was my go-ahead to test Amethyst, and honestly, it has left me speechless😮 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
This is how it pops up in Amethyst. It's not bad, but some "compact version" flag that strips away all the images clutter could be a cool. What do you think?
Is there any social client that supports embedded long-form editable events in kind-1 notes?
(Like the one I published here: nostr:nevent1qqs8jh003nmnqj0lhla97wc5lqdvx432qw3zjgllr7ejqe8t2u7sldqpzpmhxue69uhkumewwd68ytnrwghs6w0xu4)
nostr:npub1r0rs5q2gk0e3dk3nlc7gnu378ec6cnlenqp8a3cjhyzu6f8k5sgs4sq9ac
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
BOLT12 TATTOOS ARE COMING 😆⚡
(check it with your bolt12 supporting wallet ... hmm only Spark wallet?)
Cool! It seems like Parameterized Replaceable Events (NIP-33) is just the thing I've been looking for. If I understand correctly, all I'd need to do is ensure a unique d-identifier for each summary - hash(thread_note_id) could do the work. Having some attached flag that prompts clients to only show the contents, sidestepping all the "referenced event" extras, could be really neat. Is this nip widely adopted by the common clients/relays out there?
Of course, let's have a chat about it! I've been mulling over whether we really need to go as far as implementing another client. wouldn't it be neat if we could tweak things at the protocol level so that it fits nicely within notes? What's your take on this?
I'm in the middle of setting up live mirrors for the mailing lists at:
nostr:npub15g7m7mrveqlpfnpa7njke3ccghmpryyqsn87vg8g8eqvqmxd60gqmx08lk and nostr:npub1j3t00t9hv042ktszhk8xpnchma60x5kz4etemnslrhf9e9wavywqf94gll . My goal is to have AI-generated thread summaries that "auto-refresh" with each new message posted.
Here's the hitch though. I'm not certain if there's a way we can tweak an existing note while keeping all the engagements (replies, zaps, likes and all) intact. If that's a tall order, maybe we can consider something along the lines of "ndynamicevent:<>"? The idea is to flag a section in a note that points to a different "dynamic" note, one that we can update on the fly. What do you all think about that?
Just throwing it out there for some of the nostr experts:
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
I really appreciate all the insights. It's helping me get up to speed with what nostr can do.
What are your thoughts on the idea of incorporating BYOAI (Bring Your Own AI) capabilities into nostr clients? I personally find it incredibly useful to have thread summaries readily available before diving into the content/replies. It could also provide personalized notes suggestions just without the annoying ads. I'd love to hear your perspective on this!
After the successful debut of the Bitcoin Mailing List on Nostr, I'm thrilled to share that the Lightning Mailing List has now also joined the platform. ⚡
nostr:npub1j3t00t9hv042ktszhk8xpnchma60x5kz4etemnslrhf9e9wavywqf94gll
2023 threads involving multiple authors come with AI-generated summaries.
I've decided to share the workings of this project. The parsed mailing list threads data & AI summaries, presented as JSON files, is now accessible on GitHub. You'll also find the NDK-driven code that handles Nostr publishing there. It's a weekend project, so the code might reflect that! 😅
(Mailing list crawler & parser code to be added soon)
https://github.com/plebos/nostr-mailing-list-publisher
nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft
I hope these resources spur further community-driven projects. As always, I look forward to your feedback and thoughts. Let's keep this momentum going! 🚀
I haven't done so yet, but considering the positive feedback, I'm planning to set aside some time to neaten up the code and bundle it into a single service. At the moment, it looks quite like a weekend side project.
Initially, I used Python for the mailing list crawling and parsing and I moved on to JS when I've found out about NDK. I plan to publish it shortly after I finish up with the Lightning mailing list as well.
I was connecting to multiple relays and publishing all threads from 2011. Ideally, I would want the rate limit to be abstracted out so that publishing blocks until it has actually been published to 'k' out of 'n' relays.
I looked into a few options and NDK stood out as the simplest and best built. It is really tough to spot any issues.
I had to go through some nips and work out the exact tag symbols to use, which I think could be avoided. Also, I couldn't catch and handle the rate-limit exception from outside the library code.
