0x1C3B00DA

joined 2 years ago
[–] [email protected] 0 points 6 months ago

There is no better. Maybe they pick a name that's more intuitive for you, but it'd be less intuitive for someone else.

[–] [email protected] 0 points 6 months ago (2 children)

They have a pronunciation guide in their FAQ on the website. There is no branding that would be obvious/intuitive to everyone

[–] [email protected] 0 points 7 months ago

Not only are they federating with each other, but they implemented Group to Group following to help prevent duplicate posts. Its a feature that's been requested for lemmy/kbin/mbin, so it'll be interesting to see how well it works for them.

[–] [email protected] 0 points 7 months ago

which makes it that Mastodon’s implementation will not be compatible with other fediverse implementations

What a surprise! I never would have expected Mastodon to ignore compatibility with the rest of the fediverse /s

[–] [email protected] 4 points 7 months ago

consequence of the terminally-online brain rot

Disagree. Its a consequence of corporations loudly proclaiming their support for groups when it cost nothing (think Black History Month here in the US). Corporations like to use a lot of empty marketing talk about societal issues when they can get away with it and ppl have decided to fight that by pushing companies to actually takes stands. Also, corporations here in the US have much larger voices than individual (and again this is because of the corporations' own actions), so some ppl see it as a way they can actually have an influence on their govt.

[–] [email protected] 0 points 7 months ago

But wait, there's more, we're standardizing our Groups implementation so other projects can take advantage of our App and Client API.

So its compatible with lemmy but uses a different API and they want their API to be the standard for the threadiverse? This is why we should be using the C2S, but since we're not you should just stick with the lemmy api since that's where the client ecosystem is already at.

[–] [email protected] 21 points 8 months ago (6 children)

Hasbro is probably gambling that it’s the IP that made the money, and not Larian being magic in a bottle as a developer

This is probably true, but how can executives be so stupid? Every review I read praised Larian specifically and how the made a huge game with no microtransactions and tons of little loving touches. You have to be willfully ignorant to think it was the IP and not the developer and their work that people were responding to.

 

The lawsuit caps years of regulatory scrutiny of Apple’s wildly popular suite of devices and services, which have fueled its growth into a nearly $3 trillion public company.

[–] [email protected] 2 points 9 months ago

Thank you for the detailed explanation. It matches what I've heard from others while having this same debate. Now allow me to explain my side.

I have consented to functionality in which my posts are distributed to other instances within the Fediverse. It’s widely advertised and clearly explained that is how things function. I can readily find which implementations are part of the fediverse

This is the part I think is wrong and the cause of all of this. You can not find which implementations are part of the fediverse. No tracker that you can use has an up-to-date and accurate listing of implementations. New ones come online every day as some random developer builds something new. The fediverse doesn't have clear boundaries and I think the advertising that you mentioned does a disservice by implying it does. The fediverse is similar to the web; they're both based on open protocols and can be guided but not controlled, because anybody can build something on those protocols.

One response to this fuzziness has been to demand most features be opt-in. The reason I don't think this is tenable is because you have to have a hard boundary to determine what should be opt-in and what is ok to be opt-out. Your heuristic was native ActivityPub implementation. I don't think this scales (I feel like you're going to say this is a technological argument and therefore invalid, but it's also a social argument. Ppl don't want to use something that they have to constantly maintain. Constantly adding new servers/users to an allowlist is a chore that would drive ppl away. See google+ circles). It doesn't scale because like I said above new implementations pop up every day and these implementations are starting to branch away from the static archetypes we're used to (Twitter-like, Facebook-like, Reddit-like, etc). And some of them are existing projects that add AP support.

For instance, Hubzilla/Friendica has been bridging AP content for years. Do all of those instances require opt-in because they use a different protocol in addition to AP? There have also been bridges that translate RSS feeds to AP actor for years. Did the owners of those RSS feeds opt-in and should they have been required to?

What I'm trying to say is I think you're right that you can never keep up with the boundaries of the fediverse and where your posts end up. And I don't think there's an easy delineation for what should be opt-out vs opt-in. So instead we should be demanding that implementations add controls to our posts. Thinks like ACLs and OCAPs would allow you to control who can see your posts and interact with them and not care about new bridges/instances/whatever. Which is why I think the argument over opt-out vs opt-in is a distraction that will only keep the fediverse in this quasi-privacy space where you're dependent on yelling down any actor who is doing something with yours posts you don't like.

[–] [email protected] 2 points 9 months ago (2 children)

I said the two things are different, you said how does that make asking for consent for the two things different, and my response was that for one of them it already works that way without your consent. That is a clear difference. Yes, I'm talking about the technology to explain the difference, because it's a concrete fact. Your argument that a bridge should be opt-in requires an abstract boundary that some instances are are allowed to federate on an opt-out basis and others are not.

You don’t build trust in users by using practices like opt-out, which is again, the only argument I am trying to make.

The instance you're on uses opt-out practices. You didn't consent to your post federating to kbin.social and yet here we are. If you don't trust the bridge, fine, block it. Every tool on the fediverse that you already use to deal with its inherently opt-out nature is available for you to use with this bridge.

[–] [email protected] 2 points 9 months ago (4 children)

in terms of giving one’s consent, exactly how the two are different?

Because in the second case, the user is choosing to post on a network where any other server can request their posts. A bridge is just an instance that understands more than one protocol. There's no difference in it and any other server requesting your posts. That's how the network works.

[–] [email protected] 0 points 9 months ago

I wish you luck and would love to see better Interoperability, but mastodon has been against better Article support from the beginning. I'm not sure much has changed there

[–] [email protected] 2 points 9 months ago (6 children)

I think there's a huge difference in scraping your content to churn out a for-profit "AI" and federating your public posts on a federated network.

 

A conversation is a collection of messages with a common context. The ActivityStreams specifications define both collections and contexts, but very little guidance is provided on how to use them effectively. This document specifies an Acti

 

This is the proposed FEP-61cf: The OpenWebAuth Protocol. OpenWebAuth is the “single sign-on” mechanism used by Hubzilla, (streams) and other related projects. It allows a browser-based user to log in to services across the Fediverse using a single identity. Once logged in, they can be recognised by other OpenWebAuth-compatible services, ...

 

2023 marked a significant step towards our vision of radically simplifying web development. Here are the biggest updates and what’s coming up next.

 

Deno 1.40 introduces the Temporal API, TC39 decorators, and a range of deprecations and stabilizations, along with improvements in Node.js compatibility, LSP, diagnostics, and handling of unstable features, paving the way for a seamless upgrade to Deno 2.

 

You can define success any way you like. But I'm happy with the direction of the project, and I'm thankful for everyone who has helped make it happen.

 

Detecting changes in Deno KV with kv.watch makes it easier to build real-time applications like newsfeeds, analytics, multi-user collaboration tools, and more.

 

We walk through how we implemented an SSE server that's scalable and load-balanced to simplify and improve a real-time data visualization application.

 

Introducing Deno Queues - zero config, scalable messaging with a guaranteed at-least-once delivery. This new primitive builds on the foundation set by Deno KV, and is available today in the Deno JavaScript runtime and Deno Deploy.

 

“Why can we only get lamb in the US, as opposed to mutton?” That’s what Bobbie Kramer, a veterinarian near Portland, Oregon, was wondering when she

view more: next ›