hodlbod

Christian Bitcoiner and developer of coracle.social. Learn more at info.coracle.social.

Merch is available at https://geyser.fund/project/coracle/rewards

Public Key

npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn

NIP-05 Address

hodlbod@coracle.social

NIP-57 Address

hodlbod@getalby.com

Profile Code

nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhhyetvv9ujumt4w35ku7thv9kxcet59e3k7mgpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxg49md7v

Publishing to

relay.mutinywallet.com

relay.nostr.band

relay.damus.io

Author Public Key

npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn

Show more details

Last Notes

2025-04-05 17:32:03

- reply

I just don't see why you would. Why wpuldn't you just use lisp and program everything using cons cells?

2025-04-05 17:26:38

- reply

Yes, I rugged myself, it's on my list

2025-04-04 23:18:25

- reply

A lot of lists are also out of date. The first wave of projects is probably 90% dead, which can give the illusion that the whole space is too

2025-04-04 23:17:00

- reply

You'd still end up connecting to more relays than necessary. The most useful part of merging filters is figuring out which people publish to hubs and which don't, eliminating relay lists with 30 relays on them. @nprofile…8wqr @nprofile…qjvg @nprofile…0dsc have recently worked on this I think

2025-04-04 15:58:16

- reply

We shouldn't merge the PR, relays should continue to support multiple filters. But, having implemented this in coracle recently, it's actually super nice because it encourages callers to split requests by filter, which results in slightly faster response times for each result set.

2025-04-04 01:38:09

- reply

To do it for real, yes, I completely agree

2025-04-04 00:52:35

- reply

An attempt at building go on nostr: https://github.com/coracle-social/nogo/blob/master/index.html

2025-04-04 00:38:32

- reply

Keep recording it, thinking about it, even prototyping. Nostr has a lot of momentum right now, so I don't think a toy protocol will divert substantial effort away from nostr. But keep it visible enough so that if/when a successor is obviously needed we have a good starting point. It's a good project, and I think (at least for now) it "counts" as nostr

2025-04-04 00:35:45

Feeling pretty good about myself, just vibe coded 700 lines of utter garbage in only 30 minutes

2025-04-04 00:20:05

- reply

I am 35 and I still don't know how to use commas

2025-04-03 21:01:59

- reply

I mean that John may have been a nazirite

2025-04-03 17:36:31

- reply

Oh yeah, I forgot, that's Gigi 😂

2025-04-03 15:21:54

- reply

Have you published relay selections? I can't find them on your profile. If you haven't created a 10002 event, coracle will fail this way to avoid accidentally overwriting important metadata events.

2025-04-03 13:45:10

- reply

Have you tried coracle.social?

2025-04-03 00:27:09

- reply

Block their IP? Ignoring closed is definitely bad behavior. EOSE + CLOSE is forcing me to do weird hacks in coracle

2025-04-02 21:36:03

@nprofile…dwak auth.nostr1.com is sending an EOSE along with a close, which doesn't seem right to me. Is this deliberate, or a bug?
https://cdn.nostrcheck.me/97c70a44366a6535c145b333f973ea86dfdc2d7a99da618c40c64705ad98e322/d6111b09e4df10ac4dfedc089afd6a7e13850bfd9dc9de5f344612e582e1278f.webp

2025-04-02 16:14:21

- reply

Slow, I'm currently shaving yaks in the himalayas

2025-04-02 15:20:28

- reply

Big if true, I love the idea of a lower-level backend + event sourcing. This might check the box for @nprofile…20a8 as well, he and @nprofile…jyqh were talking about decoupling application logic and rendering recently.

2025-03-31 22:58:17

- reply

There is no authority, just like nostr. Embrace the chaos

2025-03-29 14:16:34

I'm honored
#nevent1q…ca5a

2025-03-27 18:26:24

- reply

Thanks, I might just do that. For now, I'm probably going to go with emitter version since I really need to get this refactor done. But let me know when you publish the rxjs relay stuff, I'd love to learn/contribute there.

2025-03-27 18:23:30

- reply

This is the most nuanced take I've seen on this subject yet.
First of all, yes, I agree github is not ideal and we should move NIPs elsewhere. But so far no one has stepped up to build a viable replacement, so for now we have to deal with the two-tier system through culture, by encouraging devs not to worry about things not getting merged. I personally have 10+ unmerged open PRs which are in varying levels of implementation in my stuff. Having them unmerged is 1. an invitation to collaborate, and 2. a signal that they're not adopted widely.
As far as lexicons go, when I was designing my own protocol that was the direction I was taking things. I'm still sympathetic to the idea, except for what you pointed out about control over the lexicon. Numeric identifiers are much better, because they're neutral — *if* we can get into a good habit of publicly signaling their use and adoption. That's not trivial of course, and points back to my first paragraph.
As far as specificity, the terseness and ambiguity is (I think) one of nostr's strengths. I could be wrong about this, because it basically goes against all the conventional wisdom of specification writing, so we'll see if it works out in practice. But specifying the minimum interoperability surface area allows there to be more flexibility in how a given data format can be used. This can lead to inconsistent UX, which is a problem but something devs are motivated to work through because it aligns with their interests, or it can lead to innovative new ideas. In either case though, it forces devs to be more conservative about how they treat events, encouraging defensive coding (in case of deliberately malformed events as an attack) and wider interoperability. This is an adaptive approach rather than a validate-and-throw-away approach.

2025-03-27 17:47:00

- reply

Yeah, I think I understand all that in the abstract, I'm just finding it quite hard to actually execute, partly because of the duplex nature of websockets, which is what I've been focusing on far, and partly due to the forking nature of streams, which makes me unsure what subscriptions need to be managed and which don't.

2025-03-27 17:43:41

- reply

Me too, and getting deeper. I hate falling down these holes 😂

2025-03-27 17:02:05

- reply

I do too. @nprofile…rxj5 is there a repository with wip code anywhere?

2025-03-27 13:07:53

- reply

Most apps do follow this. It's a dafinition based on that "plain text" recommendation, @nprofile…ucgf just didn't want us to use the term plain text, so we made up a new name.

2025-03-26 21:01:13

- reply

Yeah, the tricky part seems to be intercepting send messages so that you can buffer them and re-send after authentication (or remove reqs that have been closed before they were sent while you were waiting for auth). Here's my (half-baked) policy for that:
```
export const socketPolicyDeferOnAuth = (socket: Socket) => {
const send$ = socket.send$
const buffer: ClientMessage[] = []
const authState = new AuthState(socket)
const okStatuses = [AuthStatus.None, AuthStatus.Ok]
// Defer sending certain messages when we're not authenticated
socket.send$ = send$.pipe(
filter(message => {
// Always allow sending auth
if (isClientAuth(message)) return true
// Always allow sending join requests
if (isClientEvent(message) && message[1].kind === AUTH_JOIN) return true
// If we're not ok, remove the message and save it for later
if (!okStatuses.includes(authState.status)) {
buffer.push(message)
return false
}
return true
}),
)
// Send buffered messages when we get successful auth
return authState.subscribe((status: AuthStatus) => {
if (okStatuses.includes(status)) {
const reqs = new Set(buffer.filter(isClientReq).map(nth(1)))
const closed = new Set(buffer.filter(isClientClose).map(nth(1)))
for (const message of buffer.splice(0)) {
// Skip requests that were closed before they were sent
if (isClientReq(message) && closed.has(message[1])) continue
// Skip closes for requests that were never sent
if (isClientClose(message) && reqs.has(message[1])) continue
socket.send(message)
}
}
})
}
```

2025-03-26 18:28:33

- reply

Sounds like fun

2025-03-26 18:27:35

- reply

Because I'm writing a web client

2025-03-26 18:12:21

- reply

Cool, that's good to hear. I was like "cool, a way to avoid memory leaks". Then, 5 hours in realizing I had to deal with memory leaks.

2025-03-26 18:05:39

- reply

As in, you tried it, and went back to imperative event listeners?

2025-03-26 18:03:27

- reply

@nprofile…h7nv

2025-03-26 18:03:09

Attempting to learn RxJS because it seems like streams would be the correct way to model events flowing from a relay through various utilities for welshman. I'm currently learning about how to manage subscriptions using`takeUntil` , and it just seems like footguns and strange mental models abound.
I'm interested in others' experience with Rx*. Is it the amazing paradigm shift people say it is, or does it just make your code more obscure and come with its own problems? In anything less than something like Elm (which I do like), it seems like all you can do is move around the imperative parts of your code, not get rid of them entirely. I had my love affair with point free via ramda a number of years back, and eventually left it for non-curried utility functions (typescript especially made ramda painful). This feels very similar.
https://i.imgflip.com/9opw9g.jpg

2025-03-26 00:24:57

- reply

Nice, that's a good one, I hadn't heard it before.
"content to fill a little space, if thou be glorified." is brutal 😂 but in line with John B's "he must increase, and I must decrease"

2025-03-25 21:18:28

- reply

I agree strongly with your point about "faithful presence", while at the same time mostly failing to content myself with it. The humility and diligence that being "ordinary" requires of us is way beyond what's required to have higher (and more abstract) aspirations.
I also agree with the idea that "we need to content ourselves with it being just plain _good and faithful human work_ that helps our families and benefits our neighbors", but I also see that often becoming a reason for complacency in practice. For example, Christians often just invest in index funds without thinking about what kind of activities they are becoming complicit in.
The balance between grand vision and being "faithful in little" is so difficult I feel like I can't fit both in my head (let alone heart) at once.

2025-03-25 21:12:24

- reply

😂💯

2025-03-25 16:14:50

- reply

If you're right, I think I'm in danger of committing the sort of democratic "change the world" fallacy, where everything you do has to have global significance. I recognize that this isn't possible for everyone (and so can't be a prerequisite for a meaningful life), or even necessarily healthy for people who adopt it, but it's hard for me to let go of, and a big part of why I'm here on nostr. At the same time, I think we should have a cosmic view of the meaningfulness of our actions. How do you reconcile those two things? I'm probably just restating the question, but puzzling over this has been a challenge for me for years.

2025-03-25 15:36:22

- reply

This is the answer I was looking for, thanks!
I swim in mostly post-millennialist circles, and have lately started to feel the effects of over-realized eschatology you identified above. At the same time, I feel like God must have a place for our work, just because we spend so much time doing it. The amil answer isn't completely satisfying to me, because it seems to limit the scope of the effect our new identity as Christians has on our whole lives, but I think your reference to Jeremiah is also a good answer to that — we "mind our own business and work with our own hands" to build up the city of man not as such, but for the peace of the people within it (either evangelistically, or for the Church as a separate enclave).
Thanks for your thoughts, I'll check out those VanDrunen books.

2025-03-25 02:06:53

- reply

Tell me what you really think of me 😂

2025-03-23 21:41:17

- reply

Try coracle.social

2025-03-23 13:57:56

- reply

"This" being the old creation, right?

2025-03-23 03:58:13

- reply

Momma's spaghetti 🤤

2025-03-23 02:23:48

I have a thesis I want to run by my fellow #christians. Maybe I'm just rediscovering postmillennialism, or historic premillennialism, or something, but some of this seems original.
There are two halves of Biblical/world history: Creation and New Creation. Creation's head is Adam, whose commission is dominion. New Creation's head is Jesus, whose commission to evangelism. Dominion involves subduing physical reality to human ingenuity; i.e. technology. New creation involves subduing humanity to divine love.
We are told that this world is going to wear out like a garment, and be rolled up like a scroll, prompting apocalypticism throughout history. Yet Jesus says that the Kingdom is with you, and that it is the latter days. This is conventionally explained by the "already not yet", that New Creation is latent within our earthly lives.
But what if that is true beyond just the devotional? Jesus says the kingdom of heaven is like leaven, and we take that to mean that our souls are being saved. But what if the world itself is being saved? What if every rock, tree, ocean, cloud is being invisibly, slowly suffused by the Good News of Christ's immanent lordship over the earth? What if New Creation is slowly covering Old Creation like moss covering a rock, and when the rock crumbles away the moss will retain its shape? What if the new creation is already here, and is no less physical for it's being spiritual, and when "we see him face to face" and are changed, the rest of the world — including nature and the physical stuff we've built — are suddenly changed as well?
This fits with the idea of the "garden city" — in the Bible, cities come first, and then God irrupts into their center (for example Solomon's and Ezekiel's Temples), changing their entire nature, purpose, and organization.
This seems to me to reconcile God's apparent intention to discard this world in favor of a "new" one with his obvious love of what he has made. Thoughts? Hallucinations?
@nprofile…gpgh @nprofile…lg5q @nprofile…u5qv @nprofile…29w9

2025-03-23 02:11:25

Great day for podcasts, listen below to my undergraduate thesis advisor (and former pastor) talk with Jonathan Pageau about Biblical typology and the reconciliation of the Church:
https://fountain.fm/show/f8YMIl493SRHK2VTbLqb

2025-03-23 01:52:37

- reply

8 miles today, 26+ this summer

2025-03-23 01:10:55

Just hit 8 miles, feels good

2025-03-23 01:09:47

- reply

Nice, speaking at MIT, that's an accomplishment

2025-03-22 04:40:39

- reply

My market share is melting away

2025-03-22 04:36:44

- reply

Nice, this is pretty good. Are these hosted anywhere?

2025-03-21 21:09:58

- reply

Likely due to a parsing error on a note, is there anything in particular that's causing it?

2025-03-21 18:20:04

- reply

You can just go on a walk

2025-03-20 20:01:26

- reply

I am 35 and training for one currently. Of course, that voice has been whispering to me for 15 years at this point

2025-03-20 17:32:02

- reply

What in particular isn't working?

2025-03-20 16:20:51

- reply

In this case, I know exactly what it is, and the types come from the pit of hell

2025-03-20 15:03:52

- reply

The workflow is annoying, but go to feeds, edit -> people -> self, then search for the content

2025-03-20 13:31:01

- reply

Definitely the latter

2025-03-19 21:45:16

- reply

I haven't read that one, Lindgren is lovely

2025-03-19 18:07:35

- reply

🫂

2025-03-19 16:38:28

- reply

In NIP 22? Sure, but NIP 7D specifies not to do that:
> Replies should always be to the root `kind 11` to avoid arbitrarily nested reply hierarchies.
Maybe I should have used a different reply kind, but I don't really see why this is ambiguous.

2025-03-19 16:37:26

- reply

I think you should do that. It's ok if you don't understand why 7D exists, you don't have to use it.

2025-03-19 16:24:35

- reply

Yes, that's crucial to the definition. I made this because I want a medium that doesn't have deeply nested conversations to enforce participants to stay on topic and contribute to a single "discussion". This has implications for the user interfaces that can be built, and for how people interact on a given topic. This is really the only differentiating factor from kind 1. See flotilla's threads feature for how this looks in practice.

2025-03-19 16:22:42

- reply

30023s also allow nested replies, which kind 11 doesn't. In terms of semantics, how is a blog post distinct from a post on a forum? A lot of ways! A blog post is published within the context of an author (or publication), a forum thread is posted within the context of a topic or board. Blog posts are the focal point of the comments, a forum topic is a starting point for a longer discussion. Blog post comments may diverge into different sub-topics of the blog post, forum threads are "on topic" (or, "off-topic" as the case may be). They are entirely different media, and don't need to be squashed together.

2025-03-19 16:16:00

- reply

No, it absolutely isn't. Kind 1 allows for deeply nested reply hierarchies, 7D does not (for example). Clients should encourage longer, more complete thoughts in 7D vs kind 1s, which are context-independent and probably more memetic. It's a different medium entirely.

2025-03-19 16:11:55

- reply

One of your notes broke my parser for spotify links, I've pushed a fix which should solve this

2025-03-19 16:11:03

- reply

> I don't see the need to reinvent Kind 1 with NIP-7D.
We're not, it's a completely different concept. It's intended for use in old-school forum-like apps, not in kind 1 apps.

2025-03-19 16:00:40

- reply

I think it's mostly a UX problem. On the write side, allow a chain of self-replies. On the read side, identify self replies that happen at the same time as the parent and show those as a thread. 7D isn't the right solution, and requires completely different UI, since it doesn't allow for replies to replies.

2025-03-19 13:05:00

- reply

Different definitions of "thread" I think

2025-03-18 18:43:42

- reply

codebuff
https://codebuff.com/referrals/ref-3fcc22f4-10f9-419f-a0e9-e9d7b4368e21

2025-03-18 17:55:56

- reply

Any problem can be solved with more layers of indirection, except for too many layers of indirection

2025-03-18 02:45:43

- reply

Taking spam reports into account would fix this pretty quickly

2025-03-17 19:31:34

- reply

Just publishing to your group's relay would work (sort of), but it demonstrates the more fundamental problem, which is: why would I ask people to jump through a bunch of hoops to use a decentralized system, if they're not interested in the public broadcast part of it, which is what requires all the centralization? Might as well have custodial identities and a familiar setup. Other than the fact that people need nostr and this is a first step that direction. I just can't sell a product if there's no value proposition.

2025-03-17 18:46:39

- reply

I think it could be "solved", but privacy is essentially working against the grain of nostr. Put another way, if you don't want to reveal yourself at all you're not interested in the open network value proposition nostr offers, and so there's no reason to use nostr instead of something more centralized.

2025-03-17 17:57:19

Thinking through groups on nostr for communities that put a premium on privacy, and I'm not sure it's going to work.
You can get privacy of communication via relay authentication or encryption. But a starting point for identifying each other is to publish a public profile, which might not be desirable. And you might want to use your real name in a community, but not in public.
I'm just imagining asking a little old lady in my church (assuming she can get past the cryptographic key pair step) to permanently publish her name and picture to 8 billion people on the internet in order for her to get access to announcements about after-church potlucks. It just doesn't make any sense.
Having a single profile for your online identity violates the "selective revelation of self" principle. Even if you use different keys for different things, you ideally are only going to want to share your profile with certain people.
A possible solution to this is encryption-by-default. Only send your profile to the people and communities you want to reveal yourself to, AKA the Google+ circles model.
Have I been barking up the wrong tree this whole time? I know some people have said "nostr is for public data". I still don't completely believe this, but it's harder to work against the grain than I expected.

2025-03-17 17:42:54

- reply

I made this joke a few weeks ago to some folks at the liberal coffee shop in my town, they looked at me like I had two heads

2025-03-17 16:30:18

- reply

Smallweb creatives, illustrators, animators, cabinet makers, finish carpenters

2025-03-17 16:26:40

- reply

That's sort of what I'm thinking, if anyone can make attestations you can select which ones you trust, making it decentralized and also be able to fallback to well-known/institutional ones. You don't have to limit yourself to just one attestation either.

2025-03-17 16:22:59

- reply

Thanks for contributing! Hoping to tackle it this week or next unless someone beats me to it.

2025-03-17 15:52:03

- reply

I'd personally like to see a NIP for this; ID providers could then publish attestations (unless privacy is an issue?) and clients could fetch attestations from reputed ID providers. This would make it possible for anyone to become an ID provider.

2025-03-16 14:05:55

- reply

These are beautiful. I've never seen pictures of a safari like this.

2025-03-16 04:35:58

- reply

I bought a gamestick last week, so mario, pokemon, stuff like that

2025-03-15 20:37:51

- reply

Meanwhile here I am playing 90s games with my kids

2025-03-15 16:16:34

- reply

That makes sense, but I believe you can generate frost shards independently, which would allow multiple trusted parties to collaborate without ever seeing the full key. Of course, hand-off in such a way that no one has the whole key would also be a problem, but I think we have the basic tools

2025-03-15 15:32:16

- reply

This is very weird, thanks for the additional information

2025-03-15 15:32:04

- reply

Why is key management a non-starter? I could see companies running a relay, but I would think a pubkey would be a better way to start.

2025-03-14 20:43:01

- reply

I'm already finding it to be an incredible research tool for my book. "Hey perplexity, I heard one time that Aristotle said something about experience being formed of many memories, could you give me a citation?" "Sure, check out Book I, Chapter 1 of his Metaphysics."

2025-03-14 16:01:05

- reply

Thanks, that would be helpful

2025-03-14 15:48:07

- reply

The notifications thing is a known issue, but requires some deeper work to fix. When mutes re-appear, are the people un-muted, or are they just showing in the feed? Is there any action (like muting a note for example) that triggers it?

2025-03-14 13:09:48

- reply

Are you using any other clients?

2025-03-13 21:03:53

- reply

I'll look into it!

2025-03-13 19:12:26

- reply

So which is it

2025-03-13 17:15:18

- reply

What library? Or is this built in to flutter?

2025-03-13 16:54:30

- reply

I second this

2025-03-13 16:40:45

- reply

@nprofile…ddx7 this is why clients should just render nip19 stuff regardless of whether it's prefixed

2025-03-13 16:38:32

- reply

I personally like knowing that I'm missing context. But do you have "Ignore muted content" turned on in settings?

2025-03-12 21:04:32

- reply

😂😂😂

2025-03-12 21:01:20

- reply

Yes, Mithras, Krishna, Tammuz, etc. The parallels are either tenuous or the mythology is ahistorical.

2025-03-12 20:15:34

- reply

Categorically different from "Jesus was a Judaite from Nazareth". But also interesting how closely the crucifixion matches. Could Odin have been derived from Christ?

2025-03-12 18:09:58

"But violence ages swiftly, a few years pass—and it is no longer sure of itself. To prop itself up, to appear decent, it will without fail call forth its ally—Lies. For violence has nothing to cover itself with but lies, and lies can only persist through violence. And it is not every day and not on every shoulder that violence brings down its heavy hand: It demands of us only a submission to lies, a daily participation in deceit—and this suffices as our fealty."
- Aleksandr Solzhenitsyn

2025-03-12 18:04:46

- reply

Eichmann is interesting, I hadn't read about him before. The loss of free will in that sense definitely can and does happen. But I also resonate very strongly with Solzhenhitsyn's Live Not By Lies essay, which extends hope that we can live truthfully and freely in any situation, if we attend to it.

2025-03-12 18:00:09

- reply

Frequently