@0x1C3B00DA@kbin.social avatar

0x1C3B00DA

@0x1C3B00DA@kbin.social

This profile is from a federated server and may be incomplete. Browse more on the original instance.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

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.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

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.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

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.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

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.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

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

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

It doesn't scrape or facilitates scrapping. Your server sends your posts to the bridge and it federates it to other servers. That's how federation works. If you define that as facilitating scraping, then every instance on the fediverse facilitates scraping.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

a lot of people want nothing to do with it.

And nobody is disagreeing with their right to do that. They have the tools to curate their own experience. But they can't demand the fediverse work they way they want it to and no other way.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

the nature and direction of the fediverse

The fediverse is a decentralized network. It doesn't have a cohesive nature/direction. It's made up of servers providing twitter-like experiences, servers providing reddit-like experiences, forums, personal websites, video platforms, etc. You'll never know all the places your fediverse data has reached because the fediverse doesn't have hard boundaries so you can't possible measure it all.

Which is why I think complaining about other what other software does is pointless. Instead, users should be pushing their own software to adopt more features to allow them to control their experience and data.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

For example, free software, no advertising as a business model, not commercial, not run by big corporations and talking over AP.

None of those are requirements to be part of the fediverse. The fediverse existed long before ActivityPub was even proposed. Free software, ad free, non commercial, not run by big corporations are all just coincidence because its a grassroots effort. Even now, there's multiple companies invested in the fediverse: Mozilla, Flipboard, Facebook, Automatic being the most obvious.

Even if you take those as given, none of those dictate any shared values. Bridgy-fed itself meets all of those requirements but clearly holds differing values. Truth Social, Gab, Spinster, etc are all on the fediverse despite being abhorrent to the majority of the rest of the fediverse.

I'm in favor of groups maintaining shared values and enforcing policies based on them. But those policies can never apply to an entire network made up of distinct projects, servers, and people all with different ideas about how it should work.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I suppose this is where the root of our disagreement lies. For me the technical network that links tools is not the fediverse. The fediverse is what is built on top of that network and it is inherently linked with the community

I wrote a long reply disagreeing with each of your points, but you're right. This is our disagreement. You're using the term fediverse to apply to a specific group of ppl/servers that share values with you and I think that's co-opting the term. The fediverse is more akin to the web (a platform based on technology that allows ppl access to other ppl and information) and it doesn't make sense to talk about it as a single organization.

I think trying to change its meaning like this is flawed and leads to issues like we're having now with Bridgy-Fed. You can't shout at everyone to use the tech in the way you want, because eventually there will be ppl/orgs that just don't listen. Instead, I think you should be pushing for existing platforms you're using (lemmy, mastodon, etc) to give you more control of your own data. There are ways to allow small-fedi users to create the exact type of spaces they want and anybody else to have the wide open fediverse they want, if the various project would implement them.

I'm happy to continue discussing this with you or leave it here. Either way, thanks for the chat and have a good one.

FEP-61cf: The OpenWebAuth Protocol (socialhub.activitypub.rocks)

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...

0x1C3B00DA OP ,
@0x1C3B00DA@kbin.social avatar

OpenWebAuth has been in use on the fediverse since before WebFinger became so widely used.

Like I said in a previous comment, this FEP was written by reverse engineering the existing implementation. It's still a proposal so it still has to go through a discussion period where issues like this can be worked out and it can be updated

0x1C3B00DA OP ,
@0x1C3B00DA@kbin.social avatar

The author wrote this FEP by reverse engineering the Hubzilla implementation. The point of proposing it is to find and answer questions like these.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

In the southern United States, we have biscuits made with bacon grease and sausage rolls, which are just rolls with ground sausage baked into them.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

It shouldn’t be this hard to implement a standard structure for social media (groups/channels/sub-reddits) with an allegedly standardised protocol.

Wait til you see mastodon's proposed Group implementation, which they're intentionally making incompatible with existing Group implementations

Sublinks Aims to Be a Drop-In Replacement for Lemmy (wedistribute.org)

Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy’s Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps...

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I think the developer of PieFed is mistaken because the microblogging projects also use shared inbox a lot. My understanding is that for certain classes of posts, they actually just use it over a user's individual inbox and the remote server is responsible for delivering it from the shared inbox to the user's timeline.

Sublinks Aims to Be a Drop-In Replacement for Lemmy (wedistribute.org)

Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy's Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of...

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

That's not applicable. Sublinks is using the same standard as Lemmy/kbin/mbin, i.e. ActivityPub. In a decentralized system based on an open standard, plurality of implementations is a good thing. We shouldn't want lemmy to be the only one.

Sublinks Aims to Be a Drop-In Replacement for Lemmy (wedistribute.org)

Seems like an interesting effort. A developer is building an alternative Java-based backend to Lemmy's Rust-based one, with the goal of building in a handful of different features. The dev is looking at using this compatibility to migrate their instance over to the new platform, while allowing the community to use their apps of...

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Exactly. It's also using Spring Boot, Hibernate, and Lombok. It looks just like projects at work. It might be the first fediverse project I contribute regularly to.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Lemmy doesn't have to have missing features for someone to want to write their own implementation. And in a decentralized system you want multiple implementations to exist. This is a good thing

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I don’t think there is even activity enough to worry about those things yet.

This problem is part of why there's not enough activity. Any activity that happens in the threadiverse is spread across multiple, duplicate communities. That makes it harder for communities to build up active userbases and makes users themselves less likely to post or comment.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I submitted a proposal to lemmy a while ago to fix this and it was closed. I rewrote the proposal as a Fediverse Enhancement Proposal and a lemmy dev said on the discussion thread that they would not implement it and don't see an issue with duplicate communities.

https://socialhub.activitypub.rocks/t/fep-d36d-sharing-content-across-federated-forums/3366

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Reddit has a large enough userbase that duplicate communities can each reach a sustainable size without interfering. The fediverse userbase isn't large enough to sustain even a single community for some topics, let alone duplicates. I'm in plenty of communities where there are lots of low value posts that would normally be consolidated into a single stickied post for the community but there isn't a large enough userbase to make a stickied post worthwhile despite there being multiple communities for that topic.

Also, reddit is a centralized system. A decentralized system is going to have problems that a centralized one doesn't

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Go for the most active one

There isn't one "most active one" because federation isn't perfect and every instance sees a different number of users/posts.

The people on the other, smaller, communities will find out about the main hub and subscribe to it as well.

You can't guarantee that. If they are on a smaller instance, their instance may not be aware of the larger community/instance.

I think decentralized systems are much better than centralized systems, but they're inherently more difficult. Also, your solution (everyone eventually just uses the same community) isn't decentralized. My proposal, which the third solution in the article is based on, enhances decentralization by allowing duplicate communities to exist but consolidate the userbase and discussion.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

If the system does not depend on a central authority

In your example of coalescing on a single community, the mods of that community are the central authority.

it’s easy to coordinate a move away.

It's not even easy to coordinate everyone moving to a single community. This issue has been discussed in various forms for more than 3 years and we haven't seen this supposed consolidation of communities. Coordinating anything in a decentralized way is never easy.

That doesn’t bother me, and I truly don’t understand why it should bother others. I am not going to write only if I am optimizing reach or I know a priori if the people are going to approve.

Cool. It doesn't bother you. Then just keep doing what you're doing. If we ever get a solution to it implemented, you won't care but the rest of us will be happy for it. If you don't care, why are you all over this thread arguing about this?

This isn't about maximizing reach of our posts. It's about consolidating discussion so that communities (especially those with more niche appeal) can have a sustainable userbase and not die out from lack of activity.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Cool. I'm glad you're getting a fairly smooth experience, but that hasn't been my experience or others'. I've seen posts with only a few comments but on their home server they have whole comment trees that I didn't see. Vote counts can be around 10-20 on one server and greater than 100 on another.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I saw one recently in a linux community where a user complained about multiple "I ditched Windows" posts. I've seen requests for stickies in some gardening communities.

I assume nothing actively prevents the communities from merging other than the mods being comfortable running their communities. But they shouldn't have to merge. We can have solutions that enable multiple communities to exist while also preventing rampant crossposting and post duplication.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Because all the evidence shows...

What evidence shows that? This post is in fediverse@lemmy.world and crossposted to fediverse@lemmy.ml. There's also fediverse@kbin.social and I know I've seen others. Most of these communities have been running for a few years now and there's still no consolidation.

You can see the same pattern with communities for gaming, linux, gardening, movies, tv, etc. I'm subscribed to multiple communities for each of those topics on separate servers because the consolidation doesn't happen.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

But if you increase the userbase, you'll end up with more ppl who like yugioh and want a community which leads to duplicate communities. But for niche topics, the duplicate communities are likely to end up with userbases too small to sustain enough activity. A way to combine communities makes it more likely that users find other users who want to discuss niche topics with them. That helps to grow the userbase.

There is no point

Yes, there is. If we can keep those 5 users here, its better than them being on reddit. There's no reason not to work on this. We have multiple projects, each with multiple contributors, so we can do multiple things at one time.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I don't think we've consolidated around fediverse@lemmy.world. You're using a single post as an example. I've posted links that got 40+ comments in fediverse@kbin.social but way less in other communities. I've posted or seen threads in fediverse@lemmy.ml that got more discussion.

The merge of cooking communities on lemmy.world is also not really relevant. Those communities were each supposed to be specialized communities, not general cooking communities. They shutdown because they couldn't sustain enough activity. And they were all on lemmy.world so the userbase likely all overlapped; I'd bet that most ppl subbed to them were already subbed to cooking@lemmy.world anyway.

What I'm talking about is when small and medium sized servers (not lemmy.world) have their own communities that overlap with other communities. Users who join those servers aren't necessarily going to know about lemmy.ml or lemmy.world. They'll see communities they're interested in and sub, but then won't see as much interaction as they want. This leads to ppl just giving up and going back to the corporate sites.

Even if consolidation is happening, there's a transition period where ppl are posting in multiple places, ppl get the same post in their feed multiple times, comment threads are separate. Then when consolidation happens, you have a single community where those mods hold all the power. If we used something like the proposal above, each community could still exist but all the conversations are still consolidated. That keeps the power spread out and likely keeps each mod team in check and provides multiple on-ramps to the community. You could find movies@a.com or movies@b.com but if they're grouped, you still find the super-community. And then if one of those servers goes down, only users subbed to that community have to migrate and they should be tangentially aware of the other community so migration is easier. Their server could even handle that migration automatically.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

the Lemmy devs are not interested in this

I know. I'm the one who posted that one of the lemmy devs is not interested in this. But if the userbase gets behind it, they could convince the dev team. Kbin, mbin, or sublink could implement this and even if lemmy doesn't it would improve things for lemmy users because who follow communities hosted on those implementations and could serve as a proof of concept.

there is also the “political” aspect

Everything about the proposal is optional. Nobody would be forced to do anything, unless the owner of the community decides to go against the wishes of the community members.

Lemmy has been around for years, not months, and this is still an issue that ppl are having. Some ppl know each other and can choose to keep their communities separate. But for ppl who want larger, more in depth discussions and new ppl, this simple technical measure can make the platform better for the multiple reasons I mentioned above.

Your arguments against it seem to be:

  1. Its not needed. - I've pointed out multiple reasons I think its needed. Consolidation either doesn't happen, is never actually completed, or is a years long process. Discussions are fragmented which leads to communities that don't have enough activity. New users are unfamiliar with the platform and unaware of large players so don't know how to find the most active community. Consolidating on a single community means you've centralized the community and put it at risk if that server goes down.
  2. People might not want it - The proposal doesn't force anybody to group their communities. They can maintain their independence. I imagine that mods thinking about grouping with another community would have a discussion with the other mod team and both communities' members.

I disagree with both of those arguments but even ignoring that, I don't understand why it matters to you. You seem to be fine with the current state and this proposal wouldn't disrupt that. Either the communities you're in don't join up with others or they do and you wouldn't notice (unless a mod groups with a wildly different community)

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

That's exactly what the third proposal in the article would do. See the proposal its based on for more detail.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

The third solution wouldn't cause extra communication. If you're subbed to a community that follows other communities, you receive all the posts once. That's the same as if you followed all of those communities yourself.

If your server hosts communities that follow others, that would still be the same as having users on your server follow those servers. It's the same amount of communication.

I'm assuming you were talking about this comment. That doesn't explain why merging communities is bad, only why you may not want to do it. Which would always be an option. Having the option to merge duplicate communities doesn't mean you can't maintain similar communities without merging them.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

requires no extensions in the spec

That proposal doesnt require an extension to the spec. It requires a group to follow another group, which is definitively within the ActivityPub spec. The proposal above is written as a FEP (Fediverse Enhancement Proposal) which is the agreed upon way to propose new behavior in an interoperable way.

no changes in the server side

But it takes changes on the client side. One is not inherently better than the other. Also, doing it client side means you have to duplicate the work for every client. Doing it server side means it works for everyone.

easily prototyped/tested

Every fediverse platform already supports following Actors. That's part of the spec. Handling follows for groups is just as easy as for users.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

The proposal was intentionally written to be easy to implement. All fediverse platforms deal with follows so handling follows for groups is a simple extension to that.

Some subreddits are still not wanting to move to Lemmy

I've seen ppl saying they don't want to use any threadiverse platform because of disparate communities/threads. This issue keeps being talked about and always generates pretty big threads so its clear that its an issue that causes a lot of users friction. There's also plenty of issues that are way lower priority than this but they're still filed on various projects' trackers.

I think it's higher priority than you do and would contribute to helping the fediverse grow but I don't think we're gonna convince each other so I'm gonna bow out here.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Only if you want to force everyone to adopt this behavior

Did you read the proposal? No one is forcing anyone to do anything. The proposal would allow one community to follow another. Communities don't have to send a follow request and the other community doesn't have to follow back. This works just like users following users/communities. It's all optional.

There are tons of people here that are telling you that this is a non-issue to them, why do you think that all clients need that?

There are tons of ppl telling you it is an issue for them. If its not an issue for you, then you lose nothing if this is implemented, but ppl who care have one of their pain points solved.

it absolutely is better to delegate behavior to the nodes as much as possible... Pushing as much functionality to the client is such a good way to follow Postel’s Law that is basically second nature to those developing distributed systems.

The nodes are the servers not the clients. Your argument is the exact opposite of what every fediverse developer says. The reason most of the fediverse uses the MastoAPI (or lemmy api for the threadiverse) instead of the ActivityPub Client to Server API is because the C2S expects a more client focused ecosystem but all the developers find it easier to handle logic on the server.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

There are 500 million posts on Twitter every day. Do you read them all? There are 2.8 million subreddits. Have you browsed them all?

Nobody subscribes to every twitter acct or every subreddit so nobody is expecting to have every single post delivered to them. The fediverse has a legitimate problem where ppl don't actually receive all the posts of accts they're subscribed to. It's silly to compare what the OP is complaining about to not being able to see every post on twitter/reddit.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

no just like federating with mastodon.social doesn't make your instance a part of the Gargron fediverse. Meta can't control non-Meta instances that federate with them

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

This is nonsense. The fediverse isn't cryptocurrency. Having 51% of the fediverse doesn't give you any more control than having 1%. If your instance(s) implement a feature that the rest of the fediverse doesn't like, they can defederate.

Other instances either react by defederating, but because they only have 49 percent, due to network effects, they get extinct

If 49% of the fediverse defederates from the other 51%, it is now 100% of a new, smaller fediverse. You can't just claim that "network effects" will cause them to go extinct. Whether those instances have enough userbase to sustain a cohesive network depends on the actual number of instances/users. And the fediverse has sustained itself for over a decade with less than the current ~2 million accts and most of that time it had substantially less than 1 active accts.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

Sure, but that's already solved on the fediverse by using HTTP Signatures and isn't related to Authorized Fetch.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

It’s not sustainable to keep offering poorly designed solutions. People need to understand some basic things about the system they're using. The fediverse isn't a private space and fediverse developers shouldn't be advertising pseudo-private features as private or secure.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I downvoted because they posted about an intentionally non-federated forum in the fediverse community. The post doesn't belong here.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

I don't think an admin's permission has anything to do with it. If you post publicly on the fediverse, your posts are public. You should have the option to opt out of any indexing (just like you do for the rest of the open web). But saying its ok for you to read this post if it happens to come across your feed but you shouldn't be allowed to find it via a search is ridiculous. Users get to make the choice with each post whether its public or not, but they don't get to control how people consume those public posts.

0x1C3B00DA ,
@0x1C3B00DA@kbin.social avatar

and having a bot thrashing a server indexing everything

This is a completely separate argument and one that we already have mechanisms for. Servers can use status codes and headers to warn about rate limits and block offenders.

It is also one thing to read/interact with a site as that adds value to the site as a whole

A search index adds value as well; that's why this keeps coming up. And, again, there are existing mechanisms to handle this. A robots.txt file can indicate you don't want to be crawled and offenders can be IP blocked

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • All magazines