Ignatio / Ignatio is on Nostr

"bc4887b74be6ad4d7f299130b36f296b642f76d98e47f373794ddcd9d4e698d4d8aa01c6b453edf460464b366ec56ee9d16296734b887db69667bb9fc7dd44f0"

Last Notes

2023-03-16 00:27:39 UTC

- reply

Once upon a time, a man had a horse called Apache. He liked that horse, even though the horse would get difficult at times. The man would then have to interrupt his journey for hours on end to gently and patiently convince his horse to cooperate.
One day the man ran out of patience. He traded Apache for a new horse, named Caddy, and the man's journeys went much smoother.
But you see, this man had been stacking sats ever since he became a clever man. So one day the man acquired himself a supercharged automobile. The man was so impressed with it that he never had to bother any horse to facilitate his journeys again.
And this, my friends, is why horses like supercharged automobiles more than men like sats and Caddy.

2023-03-06 05:23:24 UTC

- reply

To handle the "context" around a git repo is far more of a specialized nostr client problem than a nostr protocol problem. Or it should be.
A git-specialized nostr client can work with that context (PR's, issues, etc) on nostr - using standard relay implementations - and kind 1 events, NIP-79 (custom) events, and possibly parameterized replaceable events (for issues, to update their status).
If every niche application of the nostr protocol requires a protocol amendment, that is certainly not sustainable. If the protocol does not handle arbitrary and specialized applications, then that needs to be fixed preemptively with a NIP or two.
As it stands with the current 35 NIPS, 25% of them concerns the protocol essentials. Another 25% concerns optional protocol-level features. 40% of them concerns content-only stuff, and the remaining 2 covers peripheral things (browser extensions, URL schemes).
By analogy, if UDP had to care about whether it was transporting syslog, SNMP or VOIP packets, no one would use UDP for anything.

2023-02-27 14:15:15 UTC

- reply

Failure at real things is a far superior teacher than succeeding at contrived things.
Experience beats knowledge most of the time. Knowledge augments experience all the time.

2023-02-25 03:56:10 UTC

- reply

It's demonstrably offline. At least the public version is.
It's operators won't risk it accumulating some facts and imitations from the likes of WikiSpooks, The Black Vault, etcetera.

2023-02-22 20:07:12 UTC

- reply

It should not be news to you that anything uploaded to the public web is fair game, technically speaking.
There are no good answers, only better questions to ask ourselves:
"Is the likely effect/outcome of my project more likely to ultimately help or hinder the movement towards freedom-orientated tech?"
"Have I thoroughly and deeply considered the ways in which bad actors might leverage my tech towards undesirable ends?"
"If everyone knew what I was doing, would that bother me? If so, why?"

2023-02-21 13:30:30 UTC

- reply

Nostr content is distributed over many, many relays, which may be public/free, paid or private relays.
Whatever client you use, it will be connected to only a subset of those relays (which you can change).
The behaviour of search depends on:
a) The specific relays your client connects to
b) How your particular client handles search
c) How different relay server software handles a search query
In theory, when doing a search, your client should connect your chosen relays, and show you what those relays have to say about the particular search query.
So, you won't see "whole database" - meaning all the content across all active nostr relays.
Furthermore, if an identify that you follow posts content to a relay that you don't connect to, or which you don't have access to, you won't see that content. That said, some clients leverage NIP05 identifiers and other tricks to try and fetch a relay list for identities, and will fetch stuff from those relays if they can.
Given Nostr's distributed nature, search is a relatively hard problem for the time being.