mewj
Bartholomew Joyce⚡️🇫🇷

The advantage of SQLite is its maturity and stability. It famously has no bugs and has 100% test coverage. I’d say that’s a reason it’s still so ubiquitous

2023-07-27 16:16:51 CEST

- reply

Yep, would love to join :)

2023-07-13 17:51:18 CEST

- reply

Yeah that’s what I’m doing for emoji as well. When rendering text I check through the text for emoji Unicode and pass all the regular text to the default renderer of NanoVG, and for the emojis I have a texture atlas. If the emojis not already in the atlas I call out to CoreText on iOS to render them for me

2023-07-13 17:15:36 CEST

@npub1xts…kk5s I worked on a client a couple months back that renders everything through NanoVG in C++, similar to your chosen stack for NoteDeck. I managed to add support for emoji rendering by writing some OS specific code (CoreText for iOS, out to HTML canvas for web, etc…).
Would you like me to try porting it to NoteDeck?

2023-07-12 19:38:49 CEST

#note1keh…z3dj

2023-07-12 19:38:22 CEST

nostr:32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245

2023-07-05 13:14:59 CEST

- reply

Complexity adds up even quicker. Lazy is the way 🙌🏻

2023-06-30 12:57:19 CEST

- reply

I added support for this in Damus, but only did the decoding part of it. At that time (maybe different now) Damus didn’t have seem to have a simple way to make relay URLs interactive. Would be nice if you could tap and then have an option to add it to your list of relays. But currently it just shows the URL

2023-06-01 17:06:26 CEST

- reply

Awesome, thanks a lot Matt!

2023-06-01 12:54:33 CEST

- reply

If you’re curious go and request your personal data from Spotify, send it over once you receive it and I’ll generate your visual.
Last year I worked hard on a version that’s fully in-browser but didn’t quite finish it. https://nostr.build/i/0d6805fefc4cdc24eb65db4ae159a3a06e2cf5427bb6e9f90f9e40b0f9e13bd2.jpg

2023-06-01 12:46:52 CEST

- reply

Ah thank you man 🙏🏻🙏🏻

2023-06-01 12:46:24 CEST

- reply

#[1] thx for the booost!

2023-06-01 12:45:56 CEST

- reply

#[1] thank you for the boost!!

2023-06-01 12:43:25 CEST

- reply

#[1] thanks for the boost 🤙

2023-06-01 12:42:01 CEST

Hey, I’m looking for work!
Have you got a big new Nostr-related idea for an app or feature that you need help developing? I’d be more than happy to lend my skills to your ideas
I’m a dev with a strong background in full-stack web, native iOS/desktop app development, and systems programming whose fallen down the Nostr rabbit hole since Nostrica and am happy to take calls to hear about your project :)
Here’s my development portfolio 👇🏻
https://bartholomewjoyce.com/
Help me out by boosting or sending this note around to people who should see it! pv

2023-05-13 14:02:21 CEST

- reply

What are you using behind the scenes for websocket management?

2023-05-13 14:01:09 CEST

- reply

Damn, AI knows what’s up 🤙

2023-05-12 13:50:33 CEST

- reply

Yeah, quite some progress! I’m preparing a full client dedicated to private DMs. It will ship originally with regular NIP-04 support, and my plan is to support a range of extensions and alternatives. There is no shortage of interesting ideas to improve DMs on Nostr, incognito DMs being pretty good. What we need now is just a client or set of clients that act as a testing ground for these ideas: bring real users to stress test the different ideas and find what works and what doesn’t.
My current thoughts on Incognito DMs/wrapped DMs is that I think the wrapped private events are a great idea that will likely be a core part of whatever the final system is, so that’s staying. But I’m not entirely sure about disposable identities/ephemeral pubkeys anymore. They are very simple conceptually, but they don’t play well with relays. Relays want real pubkeys, they want to know things are not spam. So I think the idea needs more work, but generally I’m optimistic that we can definitely find some system that both works with relays and preserves privacy.

2023-05-11 12:39:19 CEST

- reply

What kind of UI work needs to happen?

2023-05-07 14:06:58 CEST

- reply

I thought this was a chord progression

2023-05-02 21:47:53 CEST

- reply

For those interested, I’m actively working on this idea, and will hopefully have something to release soon to get this into the hands of users! I should really make an update soon covering what’s happened over the past month

2023-04-30 16:35:20 CEST

- reply

This is brilliant!

2023-04-30 14:51:41 CEST

My technical analysis of NIP-95 and file distribution over relays:
First, why do people want to distribute files directly on relays?
Well, the motivation is pretty straightforward: we want to be able to treat files like notes, meaning:
1. We can verify their authenticity
2. We can distribute them to multiple locations, and re-distribute them if the locations change
3. We can link to them without having to link to a particular hosting provider (that may go down or stop serving the file in future)
In all honestly, I agree that relays (or relay-like systems) are a perfect fit for this type of need, and I think it’s inevitable for relays to eventually start offering some form of file hosting service. Not all, but certainly paid relays might.
NIP-95 is one proposed way to get relays to host files. Dead simple: get the file contents and stick it in a Nostr event, and you’ve got files on relays! Certainly, it satisfies all three needs I mentioned earlier, so what’s wrong with it?
Well, it doesn’t appreciate how different files and notes actually are. Consider these particular behaviours that apply to files but not to notes:
1. Streaming
Files on the web are streamed in, meaning that you can see a low-resolution image well before you’ve finished downloading the full file, or you can watch the beginning of a video or beginning of a sound file without downloading it in its entirety.
If files are embedded as base64-encoded strings inside note content, a lot of this streaming behaviour that is taken care of by the browser needs to be handled manually by clients. You’ll need a streaming JSON parser and a streaming base64 parser, and if you’re lucky the note fields stream in in the right order that you can start showing the note as it’s streamed in (which is not guaranteed).
2. Seeking
Continuing along the streaming idea, files are also seekable. You can fetch a part of a file and download just that.
Again, Nostr notes don’t have such functionality at all. You get them in their entirety from beginning to end. What’s more, video files include seeking metadata at the beginning that tell a video player at what byte offset in the file they can find what second of video, enabling seeking to work. Even if you could request a specific range of a note, you’d have to play some tricks to find the right byte offset in the base64-encoded note contents that corresponds to the right byte of the file. Again, here, this is all work that comes for free in a browser, and it now is left to clients if they want to offer a good user experience.
(For those who are curious about the technical side of this, on browsers who support the MediaSource extension, you can pass a video element your own buffers of video data. So in theory clients could stream in note contents, decode them, and pass them to a video player. However, the MediaSource extension is crucially not supported on iOS, who exclusively permit Apple’s HLS streaming format.)
3. Request cancellation
Finally, to make all this magical video and file streaming work browsers frequently open requests, get what they need, and then drop the request before it’s completed. It’s the final essential behaviour that make the streaming user experience good.
How do you cancel an incoming websocket message? You have to close the websocket.
You’d have to close the websocket, re-open it, re-sub to all the things you wanted from the relay and hope to dear god that you haven’t accidentally re-subbed to the file.
To Conclude
It might sound to some like my critique here is missing the point entirely of NIP-95 files: they’re not supposed to cover all use cases for files and are generally just small images.
And that’s where I’m just not so sure. I think if NIP-95 is spec’d to only be for small files that won’t really upset relays, and that won’t really need streaming, then it’s already lost a lot of its appeal to me. Because that means it will only ever be able to solve for a subset of the problem, and the problem of actual file distribution remains open. What makes Nostr great right now is that everyone is shipping and testing lots of new wild ideas, and we all have a willingness to try and see what works, and adapt, and evolve. What’s more, there’s a certain anti-tradition mentality where nobody’s shy of questioning the established ways of doing things and that’s something that makes me really love developing for this ecosystem.
That applies just the same for file distribution. Maybe the way it’s been done traditionally isn’t THE way to do it, and novel solutions should be considered. But we risk taking steps back by not being aware of how these kind of problems have been solved traditionally and why. HTTP file streaming is very very capable, and we should try to craft something that can preserve all the great benefits of the old method while adding decentralisation and trustlessness.
And for that, I think we need to bring NIP-95 back to the workshop and give it another go. I suggest:
- file delivery happens outside of web sockets over regular HTTP (easy for clients)
- relays who host file attachments can signal to clients inside the protocol where they can go to download them
- files are hashed with a j-hash (shameless plug https://github.com/bmewj/j-hash-node), so that their contents can be verified progressively without having to download the entire file (i.e. when streamed or seeked)
Ok! That’s all. Thanks for reading! :)
Tagging a bunch of people I admire to engage (if they want) in the discussion:
#[0]
@npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj
#[1]
#[2]
#[3]
#[4]

2023-04-24 23:15:40 CEST

- reply

Harder right now, perhaps, and I agree that for the time being let’s not break images and keep them inline.
But in the long term, if we discourage referencing other notes from within kind 1s we will end up continually adding more functionality inside kind 1s instead of giving each function a separate kind. The latter is more modular and cleaner to implement, the sole pain point being that you need to pull in referenced notes in order to render the text note properly, which just isn’t reliable right now.

2023-04-24 20:20:13 CEST

- reply

Perhaps this is all due to a lack of power on the relay side. You kind of want to ask relays to send mentioned file attachment event alongside the main event in the same subscription, so you don’t have to fetch things separately that you’ll always want to process together.
But perhaps that’s straying too far from the simplicity of the protocol…

2023-04-24 20:14:36 CEST

- reply

I feel like this could work fine on Damus with a little tinkering. When Damus initially received and renders an event that mentions a file attachment it can show it as a note mention, and once it pulls in the note and sees that it’s an image file it can upgrade the display of the note from inline note mention to an inline image. If the transition can be done smoothly without screwing up your scroll position it would be nice.
It’s definitely more complicated than regular inline image URLs, because now to render you need to have both the text note and the file attachment note, but it’s not impossible.

2023-04-20 03:31:33 CEST

#[0] Are you lost?

2023-04-20 03:26:45 CEST

- reply

Oh wow I tapped the “Post” button in the thread view multiple times thinking it didn’t work, but apparently it did but the notes showed up later. And once they did finally show up the next message I was typing got cleared. Maybe the input/post button needs to be disabled while you’re sending a note?

2023-04-20 03:21:47 CEST

- reply

ahaha oh god I repeatedly tapped the “Post” button in thread view because I thought it hadn’t sent my message, but my connection is just slow. Maybe needs to be disabled and show a loading animation?

2023-04-20 03:18:41 CEST

- reply

Nos is starting to look and feel great, man!

2023-04-20 03:18:36 CEST

- reply

Nos is starting to look and feel great, man!

2023-04-20 03:18:34 CEST

- reply

Nos is starting to look and feel great, man!

2023-04-20 02:46:29 CEST

- reply

A WebAssembly Nostr client 🤫

2023-04-20 02:45:16 CEST

- reply

OH MY GOD IT WORKS

2023-04-20 02:44:42 CEST

- reply

...testing?

2023-04-20 02:44:14 CEST

Testing testing...

2023-04-15 21:34:25 CEST

- reply

Wow 🤔

2023-04-15 16:39:30 CEST

- reply

On second thought I do retract the “trivially parallelized” part. Parallelizing will add extra complexity and friction, so it’s not zero cost. But I stand by my other point of the heap allocator being the main culprit

2023-04-15 16:32:35 CEST

- reply

Yeah, on this note, first JSON decoding of multiple events can be trivially parallelized and second the rapidjson C++ lib is incredibly fast.
Finally, the biggest performance hit with this type of work is the heap allocator being used to allocate new memory for each object being decoded.
If you pre-allocate a bunch of space for the decoder output and use a format like rapidjson where the entire result uses one contiguous memory region it’ll be blazing fast without any need to make architectural changes to the protocol.

2023-04-15 13:30:56 CEST

- reply

I would add another level just below running a full Bitcoin node where you run a light Bitcoin node. Doesn’t take up significant space, you can run it intermittently to just sync the state of the network, and it allows you to verify your personal UTXOs without deferring to anyone else

2023-04-11 10:11:03 CEST

- reply

Well done, guys!

2023-04-08 17:36:57 CEST

- reply

It’s a Nostr proof-of-work generator library. You just pass in an event and a target difficulty and it returns the event with a nonce tag that produces an event id with your desired difficulty. That’s all, really.
I was just experimenting with how to get the computation to be as fast as possible. It’s a little weird compared to regular PoW in that the nonce is in plaintext, not binary

2023-04-08 12:31:24 CEST

nostr-pow: A little npm Node module for finding Nostr event nonces.
On my Mac mini 3.2GHz 6-Core i7 I’m getting about 10 megahashes/second. Curious to see what others are getting 🤔
https://github.com/bmewj/nostr-pow

2023-04-05 11:22:15 CEST

- reply

The thing is that once you start re-jigging BitTorrent to adopt a paid incentive structure you might as well opt for a much simpler protocol altogether

2023-04-04 20:39:14 CEST

- reply

BitTorrent gets a whole bunch of things right, but it’s core fault (which I think is just an unfortunate case of its design predating cryptocurrencies) is that it doesn’t distinguish people who want to consume from people who want to provide.
This is something that Nostr gets right, and why it’s got a better chance of scaling vs scuttlebutt. There are people who run relays and there are people who use clients. And it’s possible economically because relay operators can charge for the service they provide.
For the BitTorrent network to be healthy users must try to balance what they take from the network by giving back to the network. This is hardly ever the case, so you end up with leeches on one side ruining the network, and lawful users who suffer for their good will.
If you can incorporate a currency to bridge the gap between consumers and providers you have yourself a much healthier system.

2023-04-04 14:40:00 CEST

- reply

I still use it for undo and I hate it

2023-04-04 12:55:10 CEST

- reply

Oops, NIP-31*

2023-04-04 10:15:09 CEST

Incognito DMs, let’s go!
After a week of back and forth between #[0] and I we have fine-tuned and finished a first draft for NIP-32 incognito DMs.
I have created a PR for the NIP to open up our idea to discussion and feedback. We will be publishing a reference client implementation for the NIP later this week, forked from #[1] ’s Hamstr client.
https://github.com/nostr-protocol/nips/pull/410

2023-04-03 21:01:19 CEST

- reply

testing code*

2023-04-03 21:00:54 CEST

#[0] Not exactly sure what you meant regarding separating the testing and code and tlv parsing into their own functions, but for now I’ve moved all the code out to a separate file to clean things up.

2023-04-03 19:49:46 CEST

- reply

Lol

2023-04-03 11:11:57 CEST

- reply

This sounds very promising! Where does your client host the content?

2023-04-01 20:36:16 CEST

- reply

Nice nostrage! Defo worth 10 sats

2023-03-31 21:06:47 CEST

- reply

Damn, Firefox debug tools look great

2023-03-31 20:36:57 CEST

- reply

Is there anything in particular I should do to reproduce this? Is it when scrolling? DMing? Any insights you have could help get the ball rolling

2023-03-30 16:43:14 CEST

- reply

Sounds cool. What do you want to use this for?

2023-03-30 15:35:04 CEST

- reply

Cleaned it up a bunch to leave the Swift portion of the codebase as simple as possible. Added the commit to the PR!

2023-03-30 14:59:15 CEST

- reply

For the moment I’ve left the Mention object intact and have added a MentionBech32 that represents all the different Bech32 entities, but it might be easier to turn all inline mentions into Mention blocks without an index for now. Depends on how you feel about it. Don’t want to add too much complexity to your codebase :)

2023-03-30 14:56:51 CEST

- reply

Yeah I think clients should pick a default for now and worry about that later. But at the very least it will improve the privacy of DMs

2023-03-30 14:55:11 CEST

- reply

In your DM code you will now be able to have a different render_blocks() function that makes the mentions inline and doesn’t put them into the tags field without it looking any different to the user

2023-03-30 14:53:41 CEST

- reply

Haha, one reason is to make it optional when you mention someone if you want it to notify the person or not. Clients can decide whether they place mentions into the tags field or if they leave them inline. And particularly for DMs to avoid the mentions being leaked to the public they should stay inline

2023-03-30 14:48:48 CEST

Created a PR on Damus to start extending support for NIP-27 (#[0], arthurfrance, #[1])
It adds the necessary parsing code to detect nostr: bech32 entities and represent them as regular mentions. nostr:naddr and nostr:nrelay get parsed but don’t have any special UI as of yet.
With this functionality, DMs are one step away from not leaking mentions any longer. Instead of converting mentions to #[idx] they could be converted to nostr:npub… and not added to the tags field.
Any feedback is welcomed!
https://github.com/damus-io/damus/pull/837
#[2] https://nostr.build/i/nostr.build_659a71340890f104e673c20b585ff2a8c4ff8de2ce08840fa16a12bff91eaa3f.jpg

2023-03-30 01:28:34 CEST

- reply

More testing…. #note1dnl…mp9l

2023-03-29 20:56:22 CEST

- reply

Done! Hope that helps whoever’s building the video player :)

2023-03-29 20:41:07 CEST

Testing NIP-27 entities in Damus
@npub1fzd…z4dv
#note1w0t…rezw
@nprofile…hlsv
#nevent1q…n0h7
#naddr1qq…2nng

2023-03-29 20:30:29 CEST

- reply

With Apple HLS support?

2023-03-29 19:04:14 CEST

- reply

Oooh seems dope

2023-03-28 14:59:53 CEST

- reply

Ahaha it supports it but they parsed my invalid prefixes

2023-03-28 14:41:20 CEST

- reply

I wonder which clients are supporting this currently? Working on extending support of nostr:note1 and nostr:npub1 to Damus. Is this working in your client?

2023-03-28 14:26:57 CEST

- reply

Pick me! Pick me!!

2023-03-28 14:26:41 CEST

- reply

Thanks everybody for taking part in the #Nostropical hackathon vote, and congratulations to Felix and his project Nostr Follower!
#[1]

2023-03-28 11:39:42 CEST

- reply

There’s an existing protocol called XMTP that seems to use the same kind of system of sending an invitation to generate keys secretly. It’s in the alt-coin space and appears to be completely centralised for the moment, but we can certainly borrow some ideas from them https://xmtp.org/docs/dev-concepts/invitation-and-message-encryption

2023-03-28 11:37:18 CEST

- reply

Agreed. Would open up a lot of options. Our temporary solution is to generate a new private key that we encrypt and store in a replaceable event, which permits us to derive any keys we want. It helps on the author side, but for recipients we still can’t derive their keys, so still need some sort of invite

2023-03-28 10:14:16 CEST

- reply

Yes, we considered this, but to derive keys from your private key would require direct access to your key which isn’t supported through window.nostr and would require support from signing devices. Not impossible but a little harder.
And further more, if you never send invites it’ll be harder for clients to find open conversations. You’ll have to query a bunch of keys of people you follow to find conversations. So each variant comes with its own set of compromises

2023-03-28 00:42:04 CEST

- reply

Done! ❤️ all sats welcome

2023-03-27 22:37:14 CEST

- reply

Like Vitor suggested, it could help for the wrapped DMs to use a different kind so the relays are able to treat them differently from regular DMs, and optimise accordingly.

2023-03-27 22:27:04 CEST

- reply

Is this filtering happening on the client level? If so could the client accept DMs from unconnected pubkeys provided they contain a signed invite from someone in your network?

2023-03-27 19:41:08 CEST

- reply

I’m working on a pull request for Damus that will stop it from leaking mentions. NIP-27 has been drafted to deprecate the old behaviour of pulling out mentions into tag fields. That’s the most egregious bug right now. After that we need to stop publicly addressing the sender and recipient on DMs to get rid of inbox peeking

2023-03-27 19:17:01 CEST

- reply

Yep, I agree that a new kind would be better for wrapped DMs, allows relays to recognise them

2023-03-27 18:04:22 CEST

- reply

This is a good idea! And shouldn’t be too hard as Damus has already integrated nostr.build uploads in the post page

2023-03-27 18:00:02 CEST

- reply

#[6] if you’re a fan of the idea I’d be more than happy to make a pull request to Damus with an implementation of it. Can be opt-in, like a long press on the send button gives you an option to upgrade your DM to an incognito DM

2023-03-27 17:39:43 CEST

- reply

https://nostr.build/i/nostr.build_40b2d15888461a57534b19c68047ecc3fcb4ff938e84dcc05daf5886ff2598f8.jpeg
Less than a day left to vote on our submission to the #Nostropical hackathon. Here’s #[1] and I at 2am at Awake brainstorming our private DMs project (📸#[2])
You can vote by liking this post from #[3]: #[4]

2023-03-27 17:31:53 CEST

- reply

What’s the Nostr build API for uploading video? You make a PUT request with the video file?

2023-03-27 15:22:40 CEST

- reply

Great write-up!

2023-03-27 00:58:02 CEST

- reply

Our submission to the hackathon can be found here: #[5]
Right now if you upvote that post it counts as a vote for this project in the competition. So if you want to support us and get this feature out there, an upvote will go a long way!

2023-03-27 00:57:02 CEST

- reply

If you want to dig into the code (beware it’s *hackathon* code):
https://github.com/antonleviathan/hamstr
Anton and I are trying to formalise our work into a standard NIP. Here’s what we’ve got so far. If you want to chime in and help formalise it, please do! Issues and pull requests welcome:
https://github.com/bartjoyce/private-dms-nip
Once the NIP is formalised we’ll also build a standard helper library for web clients:
https://github.com/bartjoyce/nostr-incognito/
We’re very serious about getting this out into clients

2023-03-27 00:49:08 CEST

https://www.youtube.com/watch?v=tldTGhcVWX8
Here’s a video demo of “Incognito Direct Messages” - showing a forked version of Hamstr that can send private NIP-04 DMs where no metadata is leaked to the public (no more inbox peeking).
#[0] #[1] and myself developed this as part of the Nostr Hackathon organised by Hard Yaka, Universal Names and #[2].
The main idea was developed by Anton and #[3] (developer of Hamstr.to). The essential idea is to create new disposable identities for each conversation you create, you exchange these identities with your peer secretly, and then the entire conversation takes place away from your public identity. It’s very simple, it works, there are some weaknesses (you have to trust relays), but it’s a step in the right direction.

2023-03-24 01:17:55 CET

- reply

Do you have an npub for Stewart?

2023-03-24 00:18:30 CET

- reply

And then imagine timestamped replies mmm. Could become a lil audio-only subculture in the nostrverse

2023-03-24 00:17:43 CET

I would love Nostr voice notes honestly

2023-03-21 19:26:25 CET

Testing .ts video files: https://bartholomewjoyce.com/hls/video.ts

2023-03-21 19:25:10 CET

Testing HLS videos: https://devstreaming-cdn.apple.com/videos/streaming/examples/img_bipbop_adv_example_fmp4/master.m3u8

2023-03-08 15:21:09 CET

- reply

Yeah, I don’t think many relays support note deletion yet 😬 it’s rough out here

2023-03-07 23:06:51 CET

- reply

Two months later and I’m still slowly making my way through it. Incredible reading experience so far

2023-03-06 10:32:32 CET

Do relays reject notes that have non-standard tag fields?

2023-02-19 10:13:10 CET

#[0] #[1] Question about transport in Uvita: I’m arranging transport during my stay for Nostrica. Is a fourwheel drive recommended during this season to drive around in Uvita? Or will a regular car be fine? Thanks!

2023-02-16 23:28:31 CET

- reply

Thanks! Trying now :)

2023-02-15 12:14:14 CET

- reply

Hello, I’d love to try!

2023-01-19 13:39:49 CET

- reply

Try using Wallet of Satoshi