Plus I cringe at the thought of 75% of the CBC budget being spent on content moderation.

Theoretically, could they outwardly federate only? For example, they make a post which gets pushed out to other instances, but they would set their instance to not allow any external posts or comments to be federated into their instance, and they could close registrations. That way, the rest of the Fediverse could follow and interact with their content, and they wouldn’t have to deal with moderation. I’m not sure if that’s really how federation works, so please correct any inaccuracies.

[…] treat each Lemmy community as a community, not an audience.

I think it depends on the community in question, and the nature of the post. If, for example, one is looking for an answer to a question, or help with something, I would argue that one would, generally, want to target the largest relevant audience to maximize the surface area of potential people who can help. At any rate, more specifically, I don’t think it’s one or the other, but rather both — one would want to find the largest and the most relevant community. By my experience, another common behavior is to cross-post to multiple communities. This seems to be especially more common in a federated forum like Lemmy where there could be any number of duplicate communities.

As far as I understand it, a client app using UP to recieve push notifications does perform a registration step with the UP gateway (via the distributor app which communicates with the gateway via its own transport), which sets up and responds with the api endpoint details, which the client app relays to its servers, which can then send UP notifications via the specified gateway.

So, if there was to be encryption done by UP, it would be handled by the gateway? For example, for Matrix, it would then be handled by the Matrix gateway in Ntfy [1]?

Yeah, I was doing some more reading and I think it might only be the newest version of the UnifiedPush spec which requires the message to be encrypted.

The question I would then have is: Who would be responsible for updating their system to support this (ie the Unified Push encryption)? Say if we, for example, look at Matrix. Would Matrix need to modify their notification API? Would the Matrix gateway in Ntfy need to be modified? Would some other component of Ntfy be modified? Would the distributor app need to be modified? Would the end-user application need to be modified?

I know I can post and be the change I seek.

Imo, this is your answer. I’m not sure exactly what other solution you want. Content will not appear on Lemmy without someone first posting it. Advertising the platform to help draw people in is also important.

I enabled logging in the Ntfy app, and, upon receiving a message in Element X, it showed the Matrix notification push message in plain text in the logs. If Ntfy indeed doesn’t know anything about Unified Push and is just the medium through which a Unified Push message travels, then I would think that it wouldn’t be the service decrypting the message, yet it is decrypted in the logs.

So, in this image, if the application server, the push server, and the distributor app have nothing to do with Unified Push, then where exactly does it come into play? What exactly is it doing? I was of the belief that Unified Push standardized the notification communication protocol with the application server, replacing things like Google Firebase (which, iiuc, is equivalent to the push server in the above diagram, and the distributor app being built into the phone — ie Android). What’s also confusing me in all this is what exactly a push gateway is doing. Ntfy, for example, implemented a Matrix Gateway [1][2], but I’m not exactly sure the point of that if it’s not doing anything with Unified Push (Matrix uses it’s own push API [3])

So, for example, if one were to register Unified Push notifications with Matrix using Ntfy, the creation of the encrypted Unified Push notifications would be done by the Matrix Unified Push Gateway which then gets handed off to Ntfy? Is there a way to confirm that the received notification is indeed encrypted?

Yes, they can read the data.

Isn’t this contradicting the Unified Push spec? It states:

Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive). [1]

Isn’t this contradicting the Unified Push spec? It states:

Push message: This is an array of bytes (ByteArray) sent by the application server to the push server. The distributor sends this message to the end user application. It MUST be the raw POST data received by the push server (or the rewrite proxy if present). The message MUST be an encrypted content that follows RFC8291. Its size is between 1 and 4096 bytes (inclusive). [1]

What’s interesting, and is confusing me about this, is that Ntfy does not adhere to this [1]. I’m not sure how this can be.

The app that wants to provide the notifications would then be said to use UnifiedPush, right?

I will preface by saying that I am not casting doubt on your claim, I’m simply curious: What is the rationale behind why it would be so unlikely for such an exploit to occur? What rationale causes you to be so confident?

Looks like a Fractal Node 304?

Yep! I’ve found that the case is possibly a little too cramped for my liking — I’m not overly fond of the placement of the drive bay hangars — but overall it’s been alright. It’s definitely a nice form factor.

It wasn’t a deliberate choice. It was simply hardware that I already had available at the time. I have had no performance issues of note as a result of the hardware’s age, so I’ve seen no reason to upgrade it just yet.

Main Server

Services

• Jellyfin
• FreshRSS
• Borg
• Immich
• Nextcloud AIO
• RSS-Bridge

Hardware

• CPU: Intel Core i5-4460
• GPU: Nvidia GeForce GTX 760
• Memory: Kingston KHX1600C10D3/8G (8GB DDR3-1600)
• Motherboard: ASUS H81I-PLUS

OS

• Ubuntu 22.04.5 LTS

Reverse Proxy

Services

• Caddy

Hardware

• Rasbperry Pi 4 Model B Rev 1.5 (2GB)

OS

• Debian 12

Router

Hardware

• TP-Link Archer C7 AC1750

OS

• OpenWRT 23.05.5

For clarity, I’m not claiming that it would, with any degree of certainty, lead to incurred damage, but the ability to upload unvetted content carries some degree of risk. For there to be no risk, fedi-safety/pictrs-safety would have to be guaranteed to be absolutely 100% free of any possible exploit, as well as the underlying OS (and maybe even the underlying hardware), which seems like an impossible claim to make, but perhaps I’m missing something important.

“Security risk” is probably a better term. That being said, a security risk can also infer a privacy risk.

I think it’s important to also have, for context, what Joe Rogan said prior to the fight:

I’m getting ready to watch this Tyson vs Jake Paul fight like I’m watching someone cast a spell that I hope actually works. And I don’t really believe in magic. But I want to believe

Yeah, that was poor wording on my part — what I mean to say is that there would be unvetted data flowing into my local network and being processed on a local machine. It may be overparanoia, but that feels like a privacy risk.