Avatar
stєvєn cσσk
82f2cccd278fccc0a8699b81a205e433d6afda31da5e4e6b60cf27909b54073a
This is the time. And this is the record of the time...

Testing, please ignore.

lnbc1u1p3l86sppp58m57ud4nqqv2khg9nwc2z7jrd9c6y3alfsd0xd8zn3spfqq2dg8sdqu2askcmr9wssx7e3q2dshgmmndp5scqzpgxqyz5vqsp5s33zdcz7jn0dfkryy5zgtnr077m4xq68zqqdmr67arvwf26xdyzs9qyyssqa0aqhglmn3slsxus5yxh30z3fukutgjvqwn6a93vv7vysu8dwg0s4nltn69yn3l2rkuyftuf2a70uyatwk9pax8ud622luffemnjkcqqg486ee

Switched from Zeus to WoS, let's see how it goes.

Best way to check your NIP05 is verifying correctly? Getting conflicting results from different clients.

Every now and again running Arch Linux bites you in the ass. Today after an update to Librewolf it "broke" browsing, thankfully the community is first class and the issue turned out to be a couple of outdated packages, Librewolf was expecting newer versions, namely 'nss' and 'nspr'. Now I'm back in action with Librewolf! 👏

It's hard work being a kitten! 😸

To whom ever sent me 1k sats, thank you!

Cleared the cache but still the same. I'm not concerned just thought it strange.

It's funny if I check my NIP05 in a browser with Iris it shows a "NIP05valid" as true, but with the Iris mobile app it shows false. 🤷‍♂️

You should be able to mask off the outline then cut and paste that to a new image without a background.

The amount of money we've spent on beds and blankets for her to sleep and she prefers my turntable! 😡🤣

I'm the author of gossip, a desktop client not a mobile app, but I have someting to say on this. Gossip downloads only about 4MB when I start it in the morning and run it for an hour. Since that is several orders of magnitude less than some other clients, I thought I'd make a list as to why:

1. Duplicate Events - many clients subscribe to the same filters on all of the "read" relays. So if a person has 10 read relays, they get each event 10 times. They could subscribe in a way that only gets N copies, where N is set in some setting somewhere (gossip defaults to 2 or 3).

2. Not Dynamically Connecting to Relays - when clients don't dynamically connect to the 'write' relays of whoever you follow, users are incentivized to add lots and lots of relays as a hack to try to get that content, aggrevating issue 1. If clients smartly went to the write relays (based on relay lists), all of the content a user has subscribed to would arrive (in best case scenario) and users would no longer feel the need to add massive numbers of read relays.

3. Counting how many followers you have is expensive. Kind-3 contact lists are long, and you need to pull one for each follower to make such a count. Especially if done across many relays (where the same ones are pulled multiple times, once per relay), this could be 10-20 MB on it's own. Then how often is the client triggered to recount?

4. Downloading of avatars: gossip caches these so it doesn't have to re-download them. Any client that uses an IMG tag and doesn't have a browser caching is probably downloading these over and over, at worst case every time a post scrolls into view.

5. Content images and content web page pre-rendering: This can be very expensive, but is probably unavoidable on rich UI clients. Gossip is a "poor" UI client, without any images or prerendered links (it just shows links that you can click on to open your browser). But with caching, repeated downloading of the same thing can be avoided.

6. Re-checking of NIP-05 could be done periodically, perhaps daily if it failed or every 2 weeks if it passed, probably the worst strategy is every time a post scrolls into view.

There are probably others.

Reading this note on Gossip... 🤙

After having another try it looks like the failure to build from source boils down to this error "ignoring invalid dependency 'pin-utils' which is missing a lib target".