Just an explorer in the threadiverse.

  • 0 Posts
  • 47 Comments
Joined 1 year ago
cake
Cake day: June 4th, 2023

help-circle
  • You were banned from the community and are no longer allowed to post or comment there, there’s a public record of this in the modlog: https://lemmy.world/modlog?page=1&userId=29397

    The best practice is for the mod to put a comment in when they ban someone about why they did so, but there’s no such comment in your case. You’d have to look back through your post and comment history to try to guess what you did in that community around 2mo ago when the ban happened.

    It’s also a good practice IMO to do temporary bans for first offenses, but the mod in this case appears to have issued a permanent ban, so you’re done interacting in that community unless you can message a mod to request being unbanned.

    Some mods tell you when they take action, but many don’t. It would be cool if Lemmy itself notified you, but it doesn’t… you have to search the modlog to see.


  • I asked them elsewhere in the thread and Connect doesn’t have crossposting either, fwiw. I have no idea why they’re posting in this thread, their answer has nothing to do with your question.

    I have both Connect and Jerboa installed, they’re both fine. Connect looks prettier, and the search is definitely better. I end up using Jerboa more out of the two.

    When I want to cross-post from mobile I end up switching over to Lemmy’s mobile web interface, which can be saved to your home screen as a progressive web app. Not a Jerboa-native solution, but I’ve tried a lot of the Android apps and I haven’t seen any of them support a proper cross-post.




  • All fair enough. I’m not real convinced about this though:

    My guess is: A popular app will implement this feature and it will become mandatory for everyone else who wants downloads.

    I suspect some app does do this already, some definitely have ways to interact with specific instances while logged out of them. I have 6 lemmy apps or PWAs installed just to keep up with new developments there… but I couldn’t tell you the differences in community discovery between them because the federation and instance discovery problems make it unrelentingly terrible on all of them when compared to lemmyverse.net, which already supports browsing communities by instance.

    While I would love for in-app discovery to be good, the journey from where we are to where lemmyverse.net is is long enough that I don’t really see any intermediate hacks as being app-defining.


  • The idiomatic way to query communities in Lemmy is to interrogate your instance, not to interrogate the instance hosting the community. I think there are some sensible reasons for this:

    • Large instances hosting lots of communities want to delegate read workload to the many instances out there hosting users. They don’t WANT everyone coming to query the communities instance directly. That’s rather the whole point of federation. Now, will one app doing direct community-hosting queries bring down the threadiverse? No, it won’t. But it’s not how community discovery is envisioned to work, and Jerboa being developed by the lemmy devs means that it’s unlikely to employ non-federated community discovery hacks.
    • If you offer community discovery by directly querying the instance, you create another discovery problem which is equally hard to solve… which is instance discovery. OP may have a particular instance in mind already that they want to query, but as soon as querying communities by instance becomes a commonly used feature… people WILL immediately begin asking how to search instances to put into that list… which again is generally a problem that is supposed to be addressed through federation. Also if you don’t build instance discovery, you’ll have tons of reports from people who mistype instance names and can’t figure out why it’s not working.

    All of which is to say that while there is an approach that involves directly querying a specific instance… it’s a partial solution that doesn’t build toward a comprehensive one. I don’t expect the devs to move this direction, but rather to focus on fixing the community browser in lemmy and exposing those capabilities through jerboa. This is the larger job I was referring to, and although there is a shorter path to OP’s specific request, I don’t think it’s a likely one to be followed in Jerboa.





  • As others have noted, this was an issue that was frequently with Jerboa ~v0.34 or so with Lemmy v0.17.x and was attributed to the buggy websockets API. It initially stopped happening to me once lemmy.world upgraded to Lemmy v0.18.x and I got on Jerboa v0.37 or so… and most reports of it died down as well.

    But in the last couple days, I have been seeing it as well. Including today. I’m now running Jerboa v0.40 against lemmy.world with a v0.18.2 build… so it’s not websockets anymore it must be a different underlying cause. But I definitely do confirm your report of seeing the wrong post and fixing it via reloading, though I can’t explain why. I also use liftoff and voyager via m.lemmy.world and I haven’t seen the problem there. I assume it’s a local bug in Jerboa this time, rather than a protocol issue.

    So anyhoo, you’re not alone in seeing this and although folks are correct to say that a similar issue was already fixed… it’s possible to see this with fully updated Jerboa. In fact, I think it must be a bug that was introduced somewhere between v0.38 and v0.40.because it stopped happening for a while after things upgraded away from Lemmy v0.17.x and the jerboa versions form around that time.


  • It has to do with how federation works. There’s no federated broadcast to all instances in the threadiverse when a community is created. Each instance has to be taught about each community via a search. I think this was done to prevent broadcast storms due to community creation, though in normal circumstances community creation is not a high frequency activity. I think the world would be better off if community creation broadcast but was rate limited.

    At any rate, in the meantime search for communities at lemmyverse.net. It’s way WAY better than the native community browser. Then just use the native community browser to find an sub the specific thing you found in lemmyverse.


  • This leads into my next concern which is GDPR, because now i can’t be certain that a users data gets deleted upon their request and i’m not certain whether i would be liable since my instance federates with the malicious instance (which may also not be hosted in the EU which is itself problematic, and even if i’m not liable it’s still not great).

    I’m not a lawyer, but I have done compliance work, but not for GPDR… so take with several grains of salt.

    I’d be fairly surprised if other instances caching your data had any impact on your GPDR status (unless you wrongfully made that data public in the first place).

    If WordPress.com hosts an intentionally public blog post for a user, and archive.org scrapes it and saves a copy, and the user deletes it from WordPress (which correctly handles the deletion), would GPDR hold WordPress liable for a different organization retaining a copy on a different server? It would surprise me if it did, I can’t imagine how anyone could be in compliance while hosting public content under any circumstances if that were so. ActivityPub is not exactly the same as this, as it automates the process of copying data to many servers. But so does RSS and that’s not new. If this were an issue, I think we’d have seen examples of it before now.

    It’s more likely that each ActivityPub instance is a different service from GPDR’s perspective, and each instance needs the capability to delete content associated with a user upon request. But I believe deletes are already federated by default, so we’re only talking about malicious instances that deliberately ignore deletion requests. These would not be GPDR compliant, but I suspect that doesn’t reflect on your liability.

    … which may also not be hosted in the EU which is itself problematic…

    Data locality is an interesting question, but I’m again inclined to suspect that YOU are not hosting data outside the EU. Other instances are, and the liability for doing so is theirs not yours.

    If you were concerned about this, you could do whitelist federation where you explicitly add instances in appropriate jurisdictions rather than Federating by default with a blacklist. The opportunity cost of doing this is, of course, cultural irrelevance. You’d be cutting yourself off from most of the physical and virtual world in order to achieve improved data locality.

    The loss of control over content is also something that i don’t particularly like…

    This is real but rather the point of federation. If you really don’t like it, then federation is not for you. But consider multiple perspectives:

    • As a user of reddit or another centralized publishing platform, you already didn’t have control over your data. The hoster did, as did the untold millions who scraped it maliciously and silently. This does not compare favorably to the fediverse.
    • As an admin of a traditional forum like PHPBB, you do give up control in the Fediverse. Though when you account for malicious scrapers, how much you give up is debatable.
    • But as a user of that PHPBB forum, the fediverse gives you MORE control. If the admin of that non-federated forum throws a tantrum and shuts it down, the community and posts are lost. As a user in the Fediverse, federation allows users on other instances to retain their account identity, recover posts from caches, and re-establish their community elsewhere against the wishes of the previous hoster.

    Federation does require the hoster to give up power, but more than equally increases the power of users in return. Like GPDR, federation aims at increasing the data autonomy of users, but rather than focusing on privacy and data destruction to facilitate a user who wants to take their toys and go home, it focuses on how users can continue to access their data usefully in the face of an admin who want to take their toys and go home. Although the means to achieve them are often in conflict… control over data destruction and control over data preservation are two sides of the same data-autonomy coin.


  • If I install from somewhere other than the play store, can I still update from the play store later, or will I have to uninstall and reinstall again?

    I haven’t personally testing switching app stores as I have F-droid installed for other reasons and just intuitively used it from the start for jerboa. My belief though is that anytime you switch sources for an app, you’re best off uninstalling/reinstalling… and with Jerboa the worst side effect of that is having to re-login.

    … but since I also have other Lemmy apps installed to use in the meantime, I’ve been figuring I’d just wait it out…

    This is a perfectly reasonable choice, just wanted you to know what it took to get Jerboa doing it’s thing again. If you have other ways of using Lemmy you’re satisfied with, have at it.





  • I feel like this setting would be a lot more useful if it was per community. Plenty of sports communities use bots to set up gameday discussion threads that I don’t want to miss, but I DO want to miss the ocean of garbage reddit reposts drowning out actual human interaction.

    Which isn’t a critique of your very relevant suggestion, but rather a lament that people think that communities somehow get better when robots are posting junk no one reads.



  • Read up on history. You have this completely backwards. It took many years of government intervention to force them to open their networks. And in some countries banks still don’t interoperate or charge obscene rates for it.

    I have nothing backwards because I said nothing about cause and effect, you appear to have fabricated some historical error about regulation so you could have something to condescend to me about. But even so, regulators did not invent cross-network calls nor did they invent inter-bank transfers. Both of these industries had those things prior to regulatory mandates and went through “wild west” periods that have clear parallels to the fediverse today (the early 1900s for telephones and the 17th century for banks) when interoperation existed but was quite selective. My point was that mature federated ecosystems converge on valuing connectivity very highly, and the fact that this value was so clear in these two cases that it was eventually encoded in law supports rather than refutes that claim.


  • It is the ability of communities to choose not to federate with anyone else which gives Mastodon its strength.

    There are zero mature federated ecosystems where this statement is true. While the freedom to (dis)associate is foundational to federated systems as an abuse management tool, it’s existentially dangerous when deployed as an idealogical weapon or negotiating lever.

    • The internet is federated, but you don’t see tier 1 ISPs de-peering each other over arguments on social media.
    • Email (which IS a great analogy… exactly because of the precedent for combatting abuse at scale) is federated, and you don’t see major providers blackholing major providers.
    • Telephone networks and the banking system are both federated, and generally major players don’t de-peer other major players within established ecosystems.

    In all these cases, there were phases where the network was immature and these squabbles did happen. But players who isolated themselves lost relevance, and eventually the value of connecting to the wider network (with all of the challenges and opportunities that brings), became greater than the value of winning any other dispute.

    This idea that de-peering everyone you don’t like is normal and how marginalized communities get protected is only popular right now for a short while because the fediverse only just barely matters at all, and almost everyone is willing to disrupt the health of the network is truly painful ways for any reason or no reason. If the fediverse doesn’t kill itself with infighting, the groups that find ways to address their disputes while remaining connected will come to form the fediverse that matters.

    Of course, anyone who disagrees can defederate with anyone and everyone if they wish. But in so doing, they limit their own reach and relevance until eventually they’re left alone talking to themselves on a fedi-desert-island. I get marginalized communities not wanting to deal with the hassle of a growing network, but getting marginalized stories heard is one of the key ways to improve things going forward and defederate-first-ask-questions-later doesn’t help there.