Skip Navigation
General @lemmy.einval.net NormalPersonNumber3 @lemmy.einval.net

Current thoughts on Lemmy (Design)

Due to Character limit, an explanation for this post will be appended below this post as a comment.

Ideas

Federation

This section is devoted to improving the Federation experience. Part of the advantage of Federation is that you don't need to belong to any instance in particular, but still be able to access other instances/communities. Now the basic problem with this is just the initial connections, it takes time and searching to find everything you may be interested in, in which there are tools to support this. That being said, I definitely think there can be ways to better support this process, and to create a more quickly connected experience while still allowing granular curation of an instance/site.

Curation Tools

This section is essentially to assist both the ability for users, site admins and site moderators to shape the experience of an Instance/Community/Subscription.

Instance/Site Tools

Concepts and powers that belongs to a site owner or administrator.

Whitelist, Graylist, Blacklist, CustomList for Instances and/or Communities

This sort of exists, but I want to add some more granular control.

  • White List
    • To those familiar with the concept, this is pretty straightforward, but I would like for this to be more featured.
    • This is to explicitly federate with another instance, and have at least their community names show up when clicking on communities.
      • I would say provide an option to automatically federate whitelisted communities for whitelisted instances, but not required. This will just help sites/instances get up and running fast if they share interests/values.
    • Could also do this for specific communities in an instance.
  • Gray List
    • This is may be an odd one, but I think it's important.
    • When sites federate with one another, as far as I can tell, it's just automatic, as long as it's enabled.
    • My thought is that this list would simply be sites/communities that have not been vetted/explicitly approved by the admin
    • This ties in with another idea I have, where in addition to a Subscribed, Local, and All, there is another tab called Recommended or Curated, or Linked, which will be described later.
    • In addition to Admins, my idea is that users can choose whether they see communities that belong to the graylist by default.
  • Black List
    • This is kind of already a thing, but I'd like it to be slightly more granular in control
    • Not just site blacklisting, but community, just in case it's just one community that's annoying.
  • Custom List
    • A custom list that is somewhere between White List and Gray List.
    • Could be used for more curated listing_types, as the URL would seem to imply.
    • Perhaps users could create something similar for themselves, a concept not too dissimilar to the way multi-reddits work back in reddit.
    • All lists should have these controls, honestly. You could make multiple White List types, if you felt like it.

Community tools

This would be similar to instance/site tools, but more specific and limited in scope. These settings would not override site/instance settings.

  • Connected Communities
    • When on an instance, a community can explicity "connect" to another instance's community to have that other instance's community appear alongside the local one.
    • Users can override this setting for themselves.
    • A local community could theoretically allow moderators from another "connected" community to moderate the local one as well
      • Local moderators would always have the final say for what is allowed/posted in that community.

Site/Instance "Name Server"

This is inspired by a couple of technologies/ and ideas I have seen in the past. This is somewhat of a "meta" (Not the Facebook kind) idea, and to some degree, it kind of already exists with sites like Lemmy Community-Browser. However, I think it would be a good idea to have something with at least a "standard" approach.

Not dissimilar to a DNS, a separate, central server with a given standard whose purpose it is to serve Lemmy instances/sites. A site would register with the "Name Server", and a Lemmy instance could then point itself to it to "lookup" other sites automatically. These name servers could also be aware of other name servers, and ask other name servers if it cannot find what is being requested, and then update themselves if found on another name server. Distributed searching and federation.

A site/instance could choose not to do this, of course.

Searching, Sorting

Ideas that make finding and connecting to known communities easier.

Community Tags / Labels

When it comes to federating and searching sites, being able to find what you are looking for is essential. I think that being able to identify a community a tag or label would make finding an relevant community much easier.

Tags/Labels should have two aspects/properties:

A "name", and a "type"

A type should specific what kind of Label/Tag it is.

Label Tag Type Examples:

  • Franchise / Intellectual Property
    • Obviously this tag type name could use some work
    • Example tag/label names that could fit this type:
      • Star Wars
      • Marvel
      • DC
      • Lord of the Rings
      • Final Fantasy
  • Person
    • About a specific person
    • Example tag/label names that could fit this type:
      • George Lucas
      • Keanu Reeves
  • Career / Job / Role / Profession
    • About something someone does
    • Example tag/label names that could fit this type:
      • Author
      • Firefighter
  • Group
    • As in a collection of people, rather than a specific person
    • Generic example tag/label names that could fit this type:
      • A Political Party
      • American Labor Party
      • A Business or Non-profit
        • Such as Square Enix
      • An Organization or Club
        • Maybe too close to Business/non profit?
          • I was thinking of a group of people that isn't necessarily a legal entity of some kind, but those are rare
  • Hobby
    • Special Interests, done for leisure
    • Generic example tag/label names that could fit this type:
      • A Sport
        • Rugby
      • A genre of Games
        • Table Top Roleplaying Game
        • Video Games
        • Card Games
      • A Crafting/creating task
        • Knitting
        • Woodworking
  • Industry
    • A category that labels an economic category
    • Example tag names that could fit this type:
      • Finance/Banking
      • Public Safety
      • Restaurant
        • McDonalds or Wendys is an Example
      • Hospitality
        • Hotels would be an example
      • Information Technology
      • Software / Programming
  • Science
    • Example tag/label names that could fit this type:
      • Biology
      • Computer Science
      • Geology
      • Chemistry
  • More!
    • Feel free to give me more Label/Tag type ideas, this is kind of open ended, I admit

Full Label/Tag Examples:

Template:

- Name
  - Tag Type
  • Minecraft
    • Hobby
  • Biology
    • Science
  • C#
    • Industry / Hobby
      • Cases like these annoy me, because this can fit both.
        • I mean, technically almost anything can fit into Hobby, but I feel as though the majority case is Industry.
        • Perhaps tag/label names can have more than one type, and you can choose to be specific or not.
          • The purpose is to make it more searchable/identifiable, so having more than one type wouldn't be a bad thing.
        • Need Feedback
  • Writing
    • Profession / Hobby
  • Teaching
    • Profession

This part is a bit more subjective, and could warrant further discussion. I like this idea below, but it could have flaws. Feel free to give feedback to this.

When I originally envisioned tags, Communities should be able to pick one tag as the "Main" tag, but can have as many "lower power" or "sub" tags as they want. Then, a user could search by a "Main" tag name or "Main" tag type, and if they want something more specific, add rules that search the "lower power" or "sub" tags.

This could be built into the "Name Server" idea listed above.

Lemmy Concepts

These are ideas to improve features that kind of already exist in Lemmy, but would be expanded.

Custom listing_type

Originally, my idea was to have some new defaults which is still a good idea, but I have a better idea on how to implement them now.

Currently, there are three options for viewing communities on an instance: Subscribed, Local, and All

I just want an option to create and configure more of these, whether it's at the site, user level, or both.

For example, a site/instance configured "Related" listing_type that lists communities, from both Local and All that the site/instance admin configured to be "Related" to the site.

  • Other options for naming this configured listing_type could include: Recommended, Curated, Linked

This is different from All, because All contains all federated communities, whether it's related to a site/instance or not. Another filter could be related to the "White List" idea above.

A user can choose to not use those custom filters, or create their own personal filters.

Ideas for Filterable fields:

  • Instance/Site
  • Specific Communities
  • tag/label
    • Theoretical field from the ideas above
  • List (White, Gray, Custom)
    • Theoretical field from the ideas above
  • Filter Operators
    • AND
    • OR

Max limit reached, appending Usability Improvements as comment below.

1
1 comments

  • Explanation

    So, as I've been using Lemmy, I've been trying to make a list of features/requests. But my ideas are not... Complete. They're just simple ideas that may already have a feature request associated with it. So the purpose of this post is to create and share them, put my ideas on paper and see what kind of discussion can come from it. If there is already an issue on the GitHub covered by my idea, let me know! I can update this list to reference that here, so I know it's being worked on.

    Anyways, in this post above, and added to this comment below are my ideas, feel free to give feedback or additional ideas. If any of these ideas get enough traction, I'll make a feature request issue on the Lemmy GitHub. (Of course, someone else could beat me to it, too.)

    Usability improvements

    Optional URL Federating

    Currently, to federate, you have to search for an instance using the search in the upper right corner of the site. After it's searched, you can subscribe to the community from a URL templated like this:

    https://<instanceDomainName>/c/<communityName>@<targetInstanceDomainName>

    If you do not do the search first, (Read: You attempt to go to the community page before using the search function) the above URL would return 404. As a general improvement, I would say when attempting to connect to a community that has not been federated yet, it should at least attempt to federate before returning 404, saving a step.

    Built in safety:

    • Do not add, search, or federate the community unless this URL is requested by a local member that is signed into site/instance.
    • Do not federate community until the local member actually subscribes to that community.

    Separate load text for Federating

    Related to above, when searching for a community that is not yet federated, there is a delay for a community that hasn't been connected/federated to the current instance. However, when it's done searching the local site, it is still attempting to search and federate to the external site/instance.

    For this I recommend any of the following:

    • In search results, have separate sections for local and external results.
    • When it is still attempting to federate
      • It should show that it is in fact, still trying to search and/or federate
      • The message should should be distinct from a local search
        • Simple ideas:
          • Federating...
            • Advantages:
              • Simple
              • Drives home the concept
            • Disadvantages
              • Unintuitive (But then again, so is the entire concept)
          • Searching for external Community
            • Advantages:
              • More immediately clear
            • Disadvantages:
              • No side benefits like above

    Notifications issue

    If notifications are enabled on a site/instance, and a user decides to allow them, they get a notification for each tab of that site/instance that is open, instead of 1 notification total.

    End of Original Post