My pod is a very quiet place, am I doing something wrong regarding Relays?

Hello folks,
I have been following Diaspora for years, even setup a pod 7 or 8 years ago just to try it out, and took it down for various reasons. Well in the past few days Ive decided to commit to running a pod again, and I set one back up.

I am trying to understand how propagation of public posts work, and if my pod is misconfigured in some way, as I do not see any at all. I did find the relay config within the diaspora.yaml, and enabled both inbound and outbound, but I do not know if there’s more I have to do, or if perhaps my instance is not functioning properly, as I still do not see anything other than posts from folks I’ve followed.

I expect that in the “public activity” page, I should see… well… public activity from outside of my pod. I do not (again, other than public posts from people follow, or my own public posts).

What can I do to test relay messages? how can I tell if my pod is functioning properly?

Thanks!

The default outbound.url in the example config looks like a dead site but this might help from the wiki. FAQ for pod maintainers - diaspora* project wiki

And for confirmation, I saw no result searching for your diaspora id from diasp.org.

Thanks for the response.

I was able to follow accounts listed in the wiki (the section you linked), and I do see posts from them, but nothing more globally.

After reading up on how relays are intended to work, I realized that my .well-known directory was being overridden by my reverse proxy, because I use that for letsencrypt’s site validation. I removed that and switched to DNS validation. I did see some outside requests to various .well-known destinations fail before I had switched it… so maybe thats related.

I also just tried searching for and following you, and it worked. So… im not sure why you cant find me?

Yes, this is true, i wasnt sure if that was meant to just be an example URL. Where might I find other URL’s though? Ive tried looking through the wiki, nothing I can find.

I found this…

I could run my own relay. :stuck_out_tongue: Not sure that does me any good though.

You show up in a search now, but that’s probably because you’re now in one of my aspects. It would be cool to see a network diagram of which nodes are connected to which. I guess that’d require an ICMP-like facility in Diaspora’s protocol.

Unfortunately there is an issue with pods when they first set up, not getting much traffic. This is because the software works on a ‘need-to-know’ basis, in that pods communicate with those pods with whom they have an established connection – as in one account on your pod has a sharing relationship with one account on that other pod. This is an attempt to manage load on servers and traffic. (I’m not great on the technical details, but it’s something like that.)

The solution is manual: to share with accounts on many different pods. If you don’t want to share with lots of accounts from your personal account, you could set up a ‘dummy’ account to do this from, or use the pod’s admin account if that’s not your personal account.

How to find those accounts? Difficult to say; but as you start to get more traffic, you’ll inevitably see content from accounts on more and more pods. You could start with accounts like hq@pod.diaspora.software and look at the comments, and share with people there from different pods who seem interesting and sane (if you’re using your dummy account, those points are less important). And then look at their posts and see who’s been commenting from different pods.

Also as you start to get traffic on the #tags that you’re following, you can look through comments on posts with those tags to find people you might find interesting.

So it takes a bit of work and some time, but you can get there. Good luck, and I hope that helps.

The relay hasn’t been maintained for a couple of years – Jay started his own social project – and I’m not sure how compatible it is with the current version of Disaspora’s software.

1 Like

I’ve just shared with you from the HQ account (I have access to it to help answer people’s questions). That might help populate your stream, although as it’s a single-account pod, it might not.

Thanks for all the info @goob! That does help to explain it.

So are you saying the guy that hosted the relay (and maintained the git repo/software) took it down because he moved on? Couldnt someone else setup a relay? Or perhaps several someones? Seems like sort of a lynch-pin in the decentralized model.

I would consider hosting a relay, depending on what it takes hardware wise. I don’t want to get over-comitted just yet though, if you know what I mean.

I used to run my own pod as well (still runs actually, just not used) and I don’t think relays were really useful anyway. I mean they do fill your public timeline with something but a lot of it is junk traffic which ends up in your database. If you run pod for yourself you don’t want it at all and if you host it for others then perhaps they would want to see something more meaningful in public timeline rather than porn bots :slight_smile:

Goob has solid advice - it is the best to set up connections manually. Just add a lot of active posters you relatively like. Set up some “follow bot” account (account which automatically friends everyone) and add a lot of connections with it if you want.

Here’s couple of my bots I set up to help with discovery, add them if you want:

welcome@friends.deko.cloud - scans for newbie tags (#newhere on Diaspora) and reshares newbie posts so they get more exposure, provides short welcome message with some pointers

echo@friends.deko.cloud - followbot for my node, also reshares random postings from its followers every few hours

DNS servers are really good at returning lists of servers if you want to bootstrap nodes.

The point about managing load on servers and traffic is a good one. Was there a problem in the past with this or maybe with spam?

No; all I mean is that the code in that GitHub repository hasn’t been updated for a couple of years, and so it might not be fully compatible with Diaspora’s software. I imagine, though, that it mostly interacts with the federation protocol, and I don’t think that’s been changed significantly in that time, so hopefully it would be OK.

Don’t put too much weight on my words when I talk about technical matters, because I really don’t understand them! I’m very much a lay-user.

So i guess the question remains. Are there still relays? And should I use them?

Sounds like Diaspora is suffering from the same thing that anything with even a little popularity has to deal with. Spam (specifically porn spam). :wink: Would a relay that filters adult content be a possibility? I’m not usually a fan of imposed sensorship, but things like spam and porn probably don’t belong in the public feed, being populated all over the place. Or, at least, not without opting into them. This of course complicates the whole problem.

Youre bringing back memories of RBLs and anti-spam measures from my email admin days… The nightmares…

Honestly, I dont see why pods themselves couldnt just maintain a list of servers they know about (the alrerady do…) and share that list with new pods that contact them. This could propagate a truly de-centralized network, as long as usres actually reach out to each other. This would mean the first time I connect with a user on like… Joindiaspora, or some other bigger pod, my pod would instantly get a list of other pods it may never have touched otherwise.

I’m sure someone’s talked this through in the life of this project. Just thinkin outloud here.

AFAIK there is no built-in way to filter anything. In theory admin can invalidate keys of undesirable contacts thus breaking the communication or block entire offending servers on firewall, etc… but it is not a nice way of handling communication and should be used only against unacceptable abuse.

Also if you run public server then there is possibility that some of your users will want porn in their feed and if your ToS doesn’t disallow it then blocking such remote contacts will break experience for your users.

I am not sure if Diaspora offers any way to block something from appearing on public feed without blocking it completely server-wide. But users can always ignore what they don’t want to see themselves.

As for servers broadcasting everything to each other… I don’t think it is such great idea as it will create A LOT of noise. In fact it can make public feeds unreadable for some users (e.g. not everyone speaks English or is interested in English - or maybe the feed will be dominated with Spanish?) not to mention that everything your pod “knows” has to be stored in database so every pod will require more powerful hardware to process these records.

I wouldn’t want it to work this way.

I think from a filtering perspective, what I was picturing was, filter adult/unsafe/unlawful/whatever from public, but if users want to seek it out they can. Mainly so if you are just browsing around public you don’t come across stuff that’s considered illegal or widely offensive (like adult content for example). Im not saying it should be banned outright from the platform, because yes, some folks want that, and we’re not here to tell them they’re wrong. We’re quickly treading into “free speech” territory though… Dangerous waters these days. :stuck_out_tongue:

Maybe a better approach is for user accounts to have robust filtering capability. If I don’t want to see adult content, I check a box and its somehow identified and filtered for me. Like google safe search. This becomes a whole other problem of HOW do you identify it… How do the big guys like FB and insta handle it? Probably some crazy nipple detection AI. :stuck_out_tongue:

Anyway, this is all a fun discussion, but doesn’t really change anything. I will say that just as @goob suggested, now that I am interacting with more people, my feed in diaspora is improving. So all that remains is, should I disable the relay setting in my diaspora.yaml?

It actually would be really nice to be able to filter my public stream to only languages I can read… :wink:

You’ll find plenty of old threads here and in the GitHub repo about that topic…