this post was submitted on 14 Apr 2024
48 points (92.9% liked)

Fediverse

17670 readers
14 users here now

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of "federation" and "universe".

Getting started on Fediverse;

founded 4 years ago
MODERATORS
[email protected]
[email protected]
48
Could We Build a Decentralised Social Platform Rooted in Place? (carlnewton.github.io)
submitted 6 months ago by [email protected] to c/[email protected]
21 comments fedilink hide all child comments
 

cross-posted from: https://feddit.uk/post/10422101

Over the past year or so I’ve been playing with the idea of a decentralised social platform based on your location. By putting physical location at the centre of the experience, such a platform could be used to bring communities together and provide a source of local information when travelling. Please let me know what you guys think.

top 21 comments
sorted by: hot top controversial new old
[–] [email protected] 18 points 6 months ago (3 children)

I agree that physical colocation of users is important for cohesive social media, but I don't think this is how it should be done. I also don't think it could ever take off.

People also want to participate in larger stuff sometimes (national news, international news). I think honestly the reddit model has already showed us how to handle this - just split stuff into separate communities.

You can have communities for the local stuff and people can go there. You can have communities for the bigger stuff and people can also go there if they want and they don't even need to make another user on another platform or anything.

I think honestly we just need more lemmy users to join instances that match their physical location. That's part of why I made Feddit.dk, to serve as the Danish hub of the Fediverse. We have communities for each city and you could have for each town as well once there's enough users to warrant that.

[–] neatchee 5 points 6 months ago (1 children)

I tried a smaller Lemmy server first and it didn't meet my needs.

I used reddit in two specific but different ways:

  1. About a dozen subreddits that I would visit individually. Small Lemmy instances work fine for this. Just subscribe to the ones I care about

  2. Browsing r/all, taking in whatever was popular at any given moment. This only works on big Lemmy instances with wildly diverse federation.

I love the firehose of "what bizarre things bubbled to the top today? Oh snap, there's a scandal in the professional bowling community. This Farscape meme is hilarious even without context. Wow, look at that crazy picture of an owl riding another owl riding a bear" or whatever.

There was never enough content on small Lemmy servers to satisfy that itch. But scrolling the main feed on lemmy.world is good enough

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

Browsing r/all, taking in whatever was popular at any given moment. This only works on big Lemmy instances with wildly diverse federation.

I don't think the instances needs to be that big to have enough networking effect to get most of all comms. Feddit.dk for instance is relatively small but the all feed is basically identical to any other major instance.

Certainly a very small instance could have a temporary issue like this but it could be easily improved by just fetching the missing comms. And again, you can certainly find smaller instances than lemmy.world that still have all the stuff in the all feed.

[–] neatchee 2 points 6 months ago (1 children)

While you may be correct, that was my experience. As a new user, I joined two Lemmy instances, was unsatisfied with the full feed on both, and said "screw it, I'm going to the biggest server".

The problem with telling people they can fetch the missing comms are threefold:

  1. It becomes a perpetual maintenance task. New communities are being created all the time and I don't want to have to reference other servers' feeds regularly to stay up to date on the newest stuff. I might as well just be on that other server

  2. Part of the joy of the firehose is seeing when some completely obscure community has a wildly popular post that one time because it's extra funny or shocking or whatever. Those posts just won't make it to most smaller servers.

  3. It's an "unknown unknowns" problem. Sometimes you know what it is that you don't know and can go find it. But often I don't know which things I don't know, so I can't seek it out to add to my server. The beauty of a big server is that I don't have to do that legwork or even think about it.

All it takes is one user on the server subscribing to the Western Spotted Bull Frogs community for me to see it when they have a post blow up. The chances of one such user being on my server go way up here on lemmy.world. I'm sure there are smaller servers that are "good enough" in that regard. But why would I bother when I have what I want right here?

Not trying to be argumentative, just calling out what I see as a fundamental truth about Lemmy, compared to other fediverse applications. Like, on mastodon a big server's fedirated feed is more or less unreadable. That makes smaller servers appealing as it helps prioritize what makes it into the feed. On Lemmy, the voting system does that prioritization, removing one of the big reasons to avoid larger servers in the first place :)

[–] [email protected] 3 points 6 months ago (1 children)

I agree that this is a problem and Lemmy could do better at community discovery. It just feels inefficient to fetch all new communities all the time, but maybe some auto-fetching in case of popular posts should happen? I'm not sure how exactly to solve this problem.

[–] neatchee 3 points 6 months ago* (last edited 6 months ago)

That's actually a GREAT idea.

Server admins should be able to opt-in to pulling in the top N posts per hour/day/week from connected instances. Could even have an option like "if a community shows up more than X times this way, subscribe the server to that community", and then toss all that stuff into Discover section or something.

[–] [email protected] 5 points 6 months ago (1 children)

Hey! Thanks for the feedback! :D Regarding your point on whether or not it could ever take off, I've given this some thought over the last 24 hours, because I have received a lot of similar feedback. Initially it was one of the biggest things preventing me from wanting to actually attempting building it. I've come to the conclusion that if I can foster a community around it in my local area only, that would be a success for me. The nearby functionality would still work at a local level. If it grew from there, that would be even more of a success. I think with any network that's designed to be fragmented like this, there's always going to be places in which it doesn't take off or not enough people adopt it, but that shouldn't really affect whether or not it's a success at the local scale. So I've decided not to let that factor deter me.

I see your point on just using, let's say, an instance of Lemmy for my local town. This is a fair point, the solution might already be out there, but it uses a toolset that's designed for generic conversation, and not conversation around a location -- like, perhaps a specific location that I want to see or place on a map and talk about it. This is the functionality that I'm personally craving.

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

Best of luck :)

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

It kind of does work though, Jodel is already a thing and its all location based and getting users close to each other to interact.

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

So, Hometown fork of Mastodon

[–] [email protected] 3 points 6 months ago

I'll look into that, thanks. If someone has already done the work that'd be amazing!

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

The Hometown functionality isn't what I'm describing. I want something in which the experience is about physical proximity to the subject. I may be bad at explaining this. Thanks for the suggestion though.

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

Gossip protocol for instance discovery is a nice idea, I'm stealing that.

Check out what Mobilizon (a federated events platform) does to represent location in ActivityPub.

Best of luck with your project.

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

Thanks Rimu! Steal away! I just watched a video of you demonstrating PieFed. It's good to get some positive feedback from a developer with experience in building a decentralised platform, because as of yet, I don't have that.

I'll almost certainly be using ActivityPub if and when, and I'll keep in mind this address amendment :D

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

I have been thinking about this for quite some time, feel free to add me on matrix (link in bio) if you are interested to collaborate/discuss.

It's interesting to consider a few potential use-cases, as you can see below the technical requirements for each use-case can be vastly different.

Notice, I am assuming that accounts are connected, aka if someone creates a post, that post can reach users of other instances. See the "Connecting Instances" section below.

Use Case: Organizing an Event

Let's say Alice wants to organize a trivia night at the coffee shop she works at. After all the preparations, Alice needs to invite people, so she makes a post with the location, the date, and the announcement of the event.

People following Alice's (or the coffee shop's) account, will be notified of the event and choose to either attend or not. Some may even "boost" the event, so it's reaches more people.

Discovery is not optimal. It's possible, people that live nearby the coffee shop, and would have otherwise attended the event, weren't following the account, as a result weren't notified and missed the event.

Instead, if a location based feed was available, it would have allowed people to find Alice's post and attend the event. The UX for such a feed can be complex, but the backend requirements are pretty straightforward, we need to filter (and/or sort) using the location, date and tags of an event.

All in all, the volume of data is small (not a lot of events happen at the same time and the same area), and the application is not time-critical (if a post takes several of minutes to reach other users it's not an issue as the event is posted days in advance).

Use Case: Short-Term/Live Monitoring

Let's say a group wants to organize a protest march, they know that the police tends to get violent on such occasions, so they need to monitor the police's activity and alert the people accordingly.

So, they create a system where some people are responsible for monitoring the area and regularly upload posts with the exact location of the police. This allows the group to create a map that shows the locations of police blocks and adjust their route accordingly.

While the example is terrible, I believe the use-case is clear. A lot of people, need to monitor "something" that is happening "right now".

Again, probably most of the complexity lies on the UX design, but a few backend requirements are added:

  1. There is a large volume of data, and everything is time-critical.
  2. There is a need for control on who is able to posts, otherwise ill-willed users will be able to create noise and render the system useless.
  3. There is a need for control on who is able to access the information.

Keep in mind that (2) and (3) do not mean that a decentralized platform would be better suited.

Use Case: Long Term Monitoring

Let's say, during the spring, a population of ducks passes through the city. Tourists and locals alike want to watch the ducks, so they start recording sightings.

This information not only allows users that are nearby to rush to watch the ducks when there is a sighting, but also can be used to create a heatmap of the most probable locations to find ducks for a given time of day.

Technical requirements:

  1. Small volume of data, but information can be time-critical.
  2. Need to generate notifications for users interested to respond to the sighting.

trigger warning

I had SA incidents in mind when writing the above example, but I choose a more light-hearted example to avoid needlessly triggering people.

The use-case is pretty much the same. The locations are places to avoid for safety reasons, and people rushing to the scene are either searching for the perp or helping/protecting the victim.

Use Case: Information Sharing

Let's say Bob learns an interesting trivia about the statue on the town square. He creates a post about the trivia and stamps it with the location of the statue.

Here, time is irrelevant to the post, people are going to be interested in Bob's trivia years down the line. However, people need to be able to discover Bob's trivia, and a map is probably the best tool for the job.

Technical requirements:

  1. Volume of data depends on population of an area, city centers are going to have more posts that small towns.
  2. Nothing is time-critical.

Connecting Instances

Utilising this, we could create a list of Habitat instances that are relevant to a user’s current location, and then query only those instances.

I don't think this would work, habbitat.world would still have users around the globe, as a result it would be queried every time someone refreshes their feed. You may make a case that there shouldn't be such an instance, but keep in mind (a) pretty much every Fediverse platform has a few huge instances, and (b) that would exclude users located in places without a local instance (or local instances with unethical admins/mods).

I believe the existing follow-based federation mechanisms would provide a better solution. Keep in mind that fedizens don't want to see "everything" within their feeds, but a curated list of posts/events based on their choices and/or the choices of people with similar background (same instance).

[–] [email protected] 3 points 6 months ago

Honestly, these use cases all sound very cool, but I'm highly concerned about the idea of federating information that could effectively tie you to your physical location with a bunch of random servers. Even if all they see is a pseudonymous activitypub id.

[–] [email protected] 1 points 6 months ago

Thanks for this. I really appreciate (and enjoyed!) the use cases. What I have in mind is mostly the information sharing use case. I think there's been a lot of focus on such a platform "catching on" and what it means on the global scale, and I did get caught up in that for a brief moment, but I've realised that my interest on the global scale is misplaced. I want something that primarily works for a local community, and I want it to be decentralised in a fashion so that if instances decide to acknowledge each-other's existence, they'll provide the ability to look for physically close posts by pointing to each other when relevant. This might not be how the rest of the Fediverse works, or want's to work, but it seems better and actually simpler in design to me. I think I'm going to go off and try building my own thing. If nothing else, it'll be a learning experience.

[–] pufferfisherpowder 3 points 6 months ago (1 children)

Basically Jodel but decentralised? https://play.google.com/store/apps/details?id=com.tellm.android.app

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

Yes, it looks like this is a better comparison than Nextdoor in terms of features.

[–] [email protected] 3 points 6 months ago (1 children)

I think this could be easily achived with an activitypub FEP and an alternative Frontend for Mastodon etc.

Why reinvent the wheel?

[–] [email protected] 1 points 6 months ago

Hey, you're the second person to suggest that it could be achieved with Mastodon. I'll look into it, and if it can be achieved with Mastodon in the way that I'm picturing, I won't be reinventing the wheel, thanks.