I’ve been a pretty heavy torrent user for years. I’m not sure when everyone came to the conclusion that VPNs were necessary. If you stick to slightly older media on public trackers and private for really new hype stuff you’re very unlikely to get hit. Plus one letter from your isp isn’t the end of the world and you can always kick on a VPN after your first one.
Lemmy federation only starts when a user on your instance searches for and subscribes to a community on another one. So unless a user on your instance goes searching for cp it’s not really an issue.
They also host their own f-droid repo if you want one built by the developers and not f-droid. https://fdroid.fedilab.app/repo/
I couldn’t find a good one on their site so I downloaded the app. It’s a fancy notes app with templates for a bunch of different things. The hook seems to be the decentralized sync system.
Film companies aren’t generally in the business of selling the rights to their products. As you say, it’s a cash cow they can keep milking for years. They can re-release the same film on new platforms and continually contract it out to different streaming platforms for years. Why would they sell you a distribution license in perpetuity for anything resembling an reasonable cost?
Nope, I’ve seen nothing firm about them doing or not doing it, but OP asked about current information and at the moment they are open source and do not have a standards document.
As it stands I wouldn’t jump on AT for a project of mine and wouldn’t recommend it as a superior protocol on those grounds.
So when Bluesky introduces a new feature or a breaking change in the protocol anyone downstream will find out when it gets pushed, maybe a little ahead of time when it comes in as a pull request. Bluesky goes live with the change immediately, maybe in a public beta channel, maybe straight to prod, depending on their testing setup. Anyone running a bluesky compatible server becomes immediately incompatible until they rush to implement the new changes. The best user experience will be had on first party servers, driving the vast majority of users there.
For a standard defined protocol, like ActivityPub for example, to introduce a change like that it would first go to the standards comittee where it would be discussed publically with stakeholders. The changes would be published and then all parties would begin implementations at a pace that makes sense to them. It’s like when you hear about new Wi-Fi versions several years before any devices actually support them. One group doesn’t just get to come out with some crazy new change that everyone else has to reverse engineer and then race to keep up.
What Bluesky is doing might be fine and make sense for their model, whatever that may be. I just want to point out that there is a difference and it drastically changes what the future of the service will look like.
Bluesky’s protocol implementation is open source but the protocol isn’t defined by any standard. Once its open and federating, if that ever happens, anyone who wants to connect will be entirely beholden to the latest published version from bluesky and whatever protocol documentation they provide. They’re starting in the middle of the EEE playbook, anyone who wants to join in has to chase them.
As far as I know AT isn’t actually being used anywhere at the moment. Bluesky has a single server with closed registration and no federation partners. Despite being open source, AT isn’t really intended to be an open protocol.
ActivityPub, on the other hand, has a few hundred servers including several dozen large ones all federating nicely together.
I’m committed to ActivityPub. I don’t really care if the specific server backend ends up being lemmy, kbin, or something new.
As long as you have a channel with that person preconfigured and funded right? Otherwise you need to do an on chain transaction with on chain fees to set up that sub one cent transaction.