Daddy wanted to fight today.

Ratioed. Good discussion, I agree with what a lot of you are saying or at least understand it. And a small portion of you are just retarded, but that's okay because I still love you.

Baphomet statues absolutely are first amendment free speech. You are free to hate it but the whole point of free speech is to defend people and ideas you DON'T like. It is literally a slippery slope where Christians and Catholics will become censored if they don't allow devil worshipping. Sorry folks but it has to go both ways.

Wow your pool is even smaller than mine. What on earth is this? https://github.com/coracle-social/paravel/blob/master/src/util/Emitter.ts

nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft might be interested in this. The main thing missing is a piece on top that selects the best relays for filters, which is something maybe NDK can do. I'm interested in sharing code somehow.

I'm building a class in TypeScript that manages hundreds of WebSocket connections. Those sockets are Nostr relays.

Most existing Nostr pool libraries are based around finding messages from across all relays in the pool. This library does not do that, and instead focuses on the capabilities of each relay in order to avoid being rate-limited and to optimize network usage.

It is based around the lifecycle of Subscription objects. When a socket dies, it only reopens if a subscription is active. But the lifecycle of the socket itself is separate from the subscription, and a new subscription will not interrupt the state of a socket, eg if it's in exponential backoff. They merely overlap (check each other's state at key moments).

The whole thing is built on web standards. The subscription is an EventTarget, and the system makes heavy use of AbortSignal from top to bottom, greatly simplifying the codebase.

To avoid rate-limiting, it uses semaphores to limit access to each relay, so no one relay is overwhelmed by too many subscriptions. Relays can be individually configured, and it supports loading a giant config map so you can sync with a database to have granular control over relays.

Finally, it is low-level enough to build things on top of it. It requires you to provide explicit relays for each query, and it returns all messages from all relays without any signature verification or validation. Those things, while required for a functioning software, are done outside of the pool for maximum flexibility. It's a feature not a bug.

In conclusion I am building a big Nostr thing that I really need, that nobody has done before in TypeScript. You can see my progress here: https://gitlab.com/soapbox-pub/nostr-machina/-/merge_requests/1

What I mean by "you can easily circumvent it": you can stay on the server that you're on, but run a separate service on a different domain to sign fetches for you, and then transfer the response to your main site. You can do this infinitely to keep circumventing it until they switch to a reputation system. It's inevitable. The question is whether or not we should speed up that process.

Since Threads requires signed fetches, and you can easily circumvent blocks of it by switching to a new domain, it suggests they will move to a domain reputation system in the future where new domains need to become established in the network, similar to email, before federation is allowed. They are operating on a blacklist for now but it will slowly become more whitelistly as people push back.

>EU laws against closed SNS

Can you explain this? I've heard of it before, but I don't believe it.

Bluesky is proprietary software that doesn't federate. Threads is proprietary software that federates. What a world.

jessel is an engineer building AP integration at Threads: nostr:npub1lt4ppl7vswzum7ww5zjc92lad5ph3qlqaf64pkpvnwhdkuulypsqyxy39w

The plot thickens.

nostr:note10aqatxpgcl8lcccpczltxz57xl3v5e240vela2zrqs6qvjjmjqwqqwrlvu

Fellas. Mark Zuckerberg blocked Spinster because he can't handle grandma at her worst and doesn't deserve her at her best.

nostr:note1uqd47qa963vyrzufutk8rlz9sm7xe2lwyuw3zdad8c2rx0eu0dhq3el5p0

Facebook has infiltrated the Fediverse. Only one man can stop this.

It's been 24 hours and I've had to modify two fedi projects to make them compatible with Threads. Embrace Extend?

nostr:npub1ha52k0xu6gnmr2fnwzmnl7xnecmz9kyrj40ulvqhsqeljv3n5lss4zwz24 can y'all see Threads on your end? Specifically nostr:npub1vx0d6mclqzcseh3kr7q7quldtauke0wmqmt8sc0r5swtfjn3alnsv8ku9p

Well, here is my one-liner to fix federation with Threads in Pleroma. So at least we have that. https://gitlab.com/soapbox-pub/rebased/-/merge_requests/296/diffs

The Mostr bridge can successfully fetch from Threads when I run it on a different domain. It only doesn't work when the request comes from mostr.pub.

Nostrbros,

I have modified the Mostr bridge to work with Threads. It works correctly in my test environment. But it does not work in production on mostr.pub due to the issue outlined here:

nostr:note1kzv43hqvqc82raylu93t74rmepqvam2l43gkncukzqqxdwddm0pqfufukn

Fellas, I think threads.net might be blocking some servers already.

It does not work on any Pleroma servers yet. But I believe that is an unintentional compatibility issue. However some servers seem to be outright blocked.

Let me explain. Threads requires signed fetches. What that means is that every GET request to a threads.net resource needs to be cryptographically signed. Threads will then look up the signer and verify its signature.

The flow looks something like this:

gleasonator.com -> GET threads.net/zuck (signed by /actor)

threads.net -> GET gleasonator.com/actor

The request to Threads contains a signature, with information about how to verify it. Threads will then verify it by fetching info from the origin server before returning the data.

You can see Threads fetching your own server by looking at the "facebookexternalua" user agent. Try this command on your server:

grep facebookexternalua /var/log/nginx/access.log

If you see logs there, that means Threads is attempting to verify your signatures and allow you to access their data.

On Gleasonator, I am seeing logs there. It is trying to let me establish a connection, even though it fails due to a bug in Pleroma or Threads. This means Gleasonator is not blocked.

However, on Spinster, and the Mostr Bridge, I have no requests from Threads at all, despite sending signed fetches. graf reports that Poast also isn't receiving any requests.

I do not believe they are operating on a whitelist. If so, it wouldn't make sense for Gleasonator and many other widely-blocked servers like gameliberty.club to be able to fetch from Threads.

So then I thought it may just be a caching issue, or a fluke on their end. But when I make a request from Gleasonator, I get the pingback from Threads within seconds. On Spinster and Mostr, there is no attempt being made at all.

So I am starting to think they may be blocking at the server-level already. And they are blocking Poast, Spinster, and the Mostr Bridge.