Addicted to love. Flower cultivator, flute player, verse maker. Usually delicate, but at times masculine. Well read, even to erudition. Almost an orientalist.

  • 1 Post
  • 15 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle
  • Fedilab is a Fediverse client for (according to the website) Mastodon, Peertube, Pixelfed, Pleroma, GNU Social and Friendica. You can also follow kbin users (and, I assume lemmy ones as well, though I haven’t tried). The app will allow you to manage several accounts on Mastodon, Peertube and Pleroma instances.

    You can block content by keywords or phrases (either hiding them with a warning or hiding them completely) but I don’t know if you can bulk upload keywords. (You can add several keywords/phrases at a time manually.)

    Unfortunately (for you) the app is currently only available on Android.





  • Honestly Dr.manhattan was kinda dumb. “Oh I need to stop humanity from nuking itself” meanwhile I demonstrate easy ability to travel to other planets.

    Doctor Manhattan’s ability to save the human race wasn’t the issue. He was basically a god. It was his willingness. He didn’t feel the need to stop humanity doing anything:

    A live body and a dead body contain the same number of particles. Structurally, there’s no discernible difference. Life and death are unquantifiable abstracts. Why should I be concerned?



  • how I sign up to mastodon instances and whatnot with kbin

    As I understand it, you don’t sign up to a mastodon instance with kbin. Rather, kbin has the ability to act as a way of following fediverse users and hashtags in the same way as mastodon does.

    In other words, if mastodon is the fediverse’s version of twitter, and lemmy is the fediverse’s version of reddit, then kbin is a combination of the two.

    However, while kbin’s lemmy/reddit features are maturing nicely, the mastodon/twitter functions are still pretty embryonic. (Bear in mind that kbin is a young project that for most of its life had only a single developer.)

    For example:

    • On kbin you can follow fediverse users by clicking on the “Follow” button in their profile (similar to the way you can follow users on mastodon), but I don’t think there’s a way of having their posts appear on a timeline yet.
    • Similarly, while you can create a magazine that follows certain hashtags in the “microblog” section of a magazine, you can’t currently do that as part of your kbin personal profile in the way you can choose to follow hashtags on mastodon and have them appear in your feed. (And the propagation of hashtags between kbin and the wider fediverse seems to be haphazard at the moment in any case.)

    What I would recommend for now is to create a mastodon account on a mastodon instance of your choice, and treat the two ecoystems as largely independent, until kbin’s feature set matures.







  • 3. BRING OVER SOME CONTENT WHEN FIRST FEDERATING COMMUNITIES

    When an instance first federates a community, it should bring across at very least the last (let’s say) 100 threads or the last (let’s say) 7 day’s worth of threads from that community (plus associated comments), whichever is greater.

    This will prevent the following scenario: A user finds a community that’s hosted on another instance, joins the community, but then finds no evidence of activity on their instance, because when an instance federates a community, it only starts pulling across posts from that moment in time. It makes it look like the community is dead, even if it isn’t. While there may be a “Browse this community on the original instance” message, but that may well confuse people, and it doesn’t mitigate the initial impression that the community has not posts.

    Related to this - any pinned posts from a community should also be brought across by default, as these posts often contain information that a new user will find useful or that the moderators want all users to be aware of.

    4. IDEALLY BRING OVER (OR ALLOW TO BE SEARCHED/SORTED) ALL CONTENT WHEN FEDERATING COMMUNITIES

    The shelf life of posts in most communities is pretty short. If you subscribe to /news it probably doesn’t matter if you can’t see the top-ranked post from three years ago. But other communities curate content that has a much longer shelf life. A community like /askhistorians for instance, or /buyitforlife, where a user might want to search the archives for a great overview on the events leading up to the building of the Berlin Wall, or recommendations for the best compression socks. Allowing new users to search the complete history of a community, or sort posts by something like “most upvoted by all time”, makes the community more useful.

    So ideally if you subscribe to a community hosted on another instance on your home instance you should be able to browse/search/sort that community’s entire archive.

    I know you can click a link to browse a community on the original instance, but that can be confusing because suddenly you are now browsing on a site where you do not have an account.

    Copying over the entire database for a community has storage/bandwidth implications (although I would argue data consumption issues are inherent to the fediverse model, which could lead to another discussion around the fediverse’s scalability limitations). But perhaps there is a way for searches and sorts to interrogate the host instance of a community (which presumably has the most complete database) rather than the local instance.


  • 2. ALLOW COMMUNITIES TO BE DISCOVERED MORE EASILY ON UNFEDERATED INSTANCES

    Communities should automatically (unless the community owner deliberately prevents this) be registered with one or more community directory services. The lemmy/kbin community search facility should use these services by default so that a new user’s search results are not limited to communities that have already been pulled into that user’s instance.

    Multiple directory services should be available for the search service (similar to how you can switch between DNS servers) in order to eliminate single point sensitivity, which is part of the fediverse ethos.

    The current method of finding new communities not already federated (“enter the exact, direct address of the community, and/or search and wait for a day before any results show up for anything not already on this instance”) should be deprecated and only be used in the event these community directory services are down.

    This will prevent the following scenario: A new user chooses an instance, creates an account, and searches for a community related to their interest on that instance. They may find a popular community (eg /gaming), because other users on that instances have already joined it (or because someone has created this community on their instance). But even moderately obscure communities will likely not appear in the search results because they’re hosted on another instance, and nobody on this instance has subscribed to them yet. This makes it look like the fediverse is a lot emptier than it actually is, because niche communities (the long tail of communities that are the secret sauce of reddit’s success) are difficult to discover.

    Basically, every community should easily be discoverable from any instance on first search (unless the community owner deliberately chooses to hide their community from the directory services).

    I know there are already some websites that act as a directory of communities, but you have to be aware of these in order to use them. They are not built into the native community search functionality of lemmy or kbin, so 99% of users (especially new users) will not be aware of them.


  • 1. MAKE FEDIVERSE-WIDE SEARCH MORE FRIENDLY

    Search should, by default (ie unless constrained by the user), search communities and posts and users, and present the results grouped into these categories, with communities displayed first or at least prominently.

    The current default fediverse search screens - especially on lemmy - are intimidating and require the user to know how the fediverse works before searching, eg knowing the difference between “local” and “all” or the difference between a “community” and a “creator”.

    Rather than putting the onus on the user to narrow search parameters before searching, have a general search bar that group the results after searching into easily distinguishable groupings, ie communities, posts and users.

    Reddit search does this very well, and offers additional quality-of-life features like suggesting communities related to your search term even as you type.

    Advanced users should still be able to specify search parameters in more detail up front of course, but it’s important to hide any complexity from new users.