Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

The problem of cross-community posting

Fediverse
56 23 120
  • Hmm... that's nice, but the comments are still separated.

    It would be better if the separate reply chains were integrated but I know there are potential issues that need to be thought through.

  • Nah, because if if there's a post that's of interest to more than one community, and I'm only in one of those, then I probably don't want to see comments from those other communities, because they will be related to topics/aspects that I'm not here for (otherwise I'd also be subscribed to those communities).

    From a discoverability standpoint it would be beneficial to see other communities' conversations on the same post.

  • How does moderation work in this case?

    That's one of the issues that need to be worked through. It's a totally legitimate concern.

    In cases where communities with polarising viewpoints discuss the same topic, it would lead to inter-community disputes and exacerbate some instance relationships.

    One solution would be to have the original community be responsible for moderation, and moderation actions from cross-posted communities only affect their "view", so to speak.

    I don't know what the answer is quite yet.

  • That's one of the issues that need to be worked through. It's a totally legitimate concern.

    In cases where communities with polarising viewpoints discuss the same topic, it would lead to inter-community disputes and exacerbate some instance relationships.

    One solution would be to have the original community be responsible for moderation, and moderation actions from cross-posted communities only affect their "view", so to speak.

    I don't know what the answer is quite yet.

    and moderation actions from cross-posted communities only affect their “view”, so to speak.

    But then if someone posts insults (just to take a simple example), then the original community mods would have to moderate it, and can't rely on the cross-posted communities mods? Wouldn't that lead to cross-posted communities mods just consider that the original community mods are the ones responsible for the moderation, and leave it up to them?

    And in that case, then the OG community mods would probably just prefer all the comments to happen on their community where they can delete comments and ban people.

  • Are the posts and communities so strictly structured that a post cannot be a part of multiple communities?

    That's my understanding. If I understand correctly, a post belongs to a single community, but two posts referring to the same URL will be identified as such by Piefed, which is how the crossposts community consolidation happens.

    In NodeBB categories and topics are all distinct elements, and the fact that a topic belongs in a category is contrived. A topic could be part of a user (pinned topics anyone?), a group (group only conversations?), or in this case… multiple categories.

    Interesting, there's definitely discussions to have about how to map that with the Piefed/Lemmy structure

  • They are separated because communities have different rules and different moderation teams.

    I know as a user that the same comment on instance A and instance B would be perceived differently. I also know that if I report a comment, it will be reviewed by different mod teams.

    As a mod, having a clear view of what comments have been made in my community and which ones have not also helps.

  • From a discoverability standpoint it would be beneficial to see other communities' conversations on the same post.

    You can already do that in Lemmy and piefed - crossposts are listed at the top

  • The different communities on Piefed are still separated within the post. You can still see which community you would be replying to

    I'm thinking more about less clutter while reading

  • I'm thinking more about less clutter while reading

    It's not that cluttered. Have you looked at how it looks on piefed?

  • Fediverse projects are maturing and adoption of them is trending up. I'm excited for the further development of the underlying technologies as well as the apps being built to leverage those technologies into even more integrated, user-friendly experiences.

    With any developing tech, small annoyances are found and ultimately patched or worked around. It's to be expected that no user experience is ever perfect, even for matured ecosystems. Typically, some smaller annoyances are tolerated when balanced with the overall utility and usefulness of the tech.

    One of the issues I've noticed (and I'm sure I'm not the first or only), is that when posts are relevant enough that the OP decides to cross-post into multiple communities, the comments and engagement stays with each community post leading to separate conversations.

    The existance of separate conversations itself isn't necessarily a bad thing. Maybe you post a recipe for Pot Roast in a general cooking community and also a community that helps refine recipes to improve them. It may be that the two separate conversations make more sense as the nature of discourse is focused on two different aspects of the content posted. If they were combined, it would be more difficult to sift through chatter to get at the discussion you were looking for.

    This concept is true for different communities as well as different instances. Maybe the Pot Roast recipe conversation generated on lemmy.carnivores is substantly different from the conversation at lemmy.vegan-curious and the existance of both is bolstered by the cultures and seneabilities of the different instance/communities. That could create usefull and/or thoughtful discourse that maybe wouldn't have happened if everyone was mixed together and talking past each other.

    However, there are plenty of informative posts attached to very similar communities on a given instance as well as posted to mirror-communities across separate instances. Each individual post is a separate entity and i find myself jumping in to different conversations of the same content to see what's being said in each. In addition to general replies often asking the same questions across all of the posts, unique engagement is diffuse and not connecting.

    I imagine that an OP would have trouble keeping up with all of these different interactions and likely defaulting to paying their attention to only one or two while the remaining posts are left to fend for themselves. Even if the OP stayed on top of them all, I assume they'd often have to answer the same questions multiple times.

    _The question I pose is: _

    What is the solution to myriad and diffuse conversations around cross-posts? Is there a way to handle this situation thru lemmy-ettiquette or does it require a technological solution?

    Maybe we handle it thru culture and expectation. If the decided upon method was to post once and then link that post to other communities for exposure, maybe that funnels everyone into one post to interact (when that's what OP wants).

    Is there a software solution on the app developer level that combines like posts together? Is it a protocol level solution thats required? Maybe something that allows a single post to essentially 'tag' different communities for exposure, while only posting once? Can we associate posts to an individual user rather than associating the post to a community, so all replies come to the user post rather than in a community?

    I don't know what the solution looks like and I'm not savvy enough to understand the protocol/software side to know if any of my examples are realistic. I also don't know if this is an issue for anyone else, or at least one that lemmy-ites actuallly care about enough to try and solve.

    Does anyone know if work is being done to address this? Am I focusing on something that is simply not a priority? I welcome your thoughts.

    ...I tried to choose what I thought was the best place for this post, but I'm open to moving it if I was in error. (Ironically, something that might be easier if posts were handled differently). :)

    From what I recall, I believe that Reddit handles crossposts in a similar manner, that is, comments in one crosspost in one subreddit don't show in other crossposted subreddits.

    Like Blaze mentioned in another comment, one of the problems with putting all the comments together is that different communities have different rules, so a comment that would be fine in one community might get you in trouble in a different community. People already get confused by this as it is. If all the comments from different crossposts get aggregated in one place, I think it would cause complete confusion and more work for mods.

  • From what I recall, I believe that Reddit handles crossposts in a similar manner, that is, comments in one crosspost in one subreddit don't show in other crossposted subreddits.

    Like Blaze mentioned in another comment, one of the problems with putting all the comments together is that different communities have different rules, so a comment that would be fine in one community might get you in trouble in a different community. People already get confused by this as it is. If all the comments from different crossposts get aggregated in one place, I think it would cause complete confusion and more work for mods.

    Piefed splits up the comment boxes based on community when a thread is crossposted, so you can still distinguish between the comment boxes on different communities despite them being visible.

    That said, a potential future option here would be a community opt-out of crosspost functionality in this way

  • From what I recall, I believe that Reddit handles crossposts in a similar manner, that is, comments in one crosspost in one subreddit don't show in other crossposted subreddits.

    Like Blaze mentioned in another comment, one of the problems with putting all the comments together is that different communities have different rules, so a comment that would be fine in one community might get you in trouble in a different community. People already get confused by this as it is. If all the comments from different crossposts get aggregated in one place, I think it would cause complete confusion and more work for mods.

    What if upon cross-posting the default is separation, but a request is sent to the original community to request a comment tree merge?

    Then you don't have to share comment space with the tankies unless you wish it

    cc blaze@piefed.zip

  • Alternative suggestion - allow communities to block crossposting functionality with specified communities in the community settings.

  • Every instance should simply just stop thinking they should have their own version of X community.

    Doesn’t PieFed merge communities with the same name?

    Shall we keep memes on Beehaw or .ml?

  • As mentioned in another comment, as a mod there's not a lot of value mixing other comments I cannot mod about to the ones I can mod. Seems like an easy way to abuse the system and avoid moderation

  • the conversations should be combined

    Disagree. As OP points out, there is value in separating the discussions as well.

  • Different conversations in different moods and cultures on the same subject are something completely human and normal, and tech should not work to undo this. When we have seen tech undo this is with social media silos, after all.

    Which is to say, any "solution" that integrates those conversations into one view should be, where possible, client-side only. That way I can opt in to view some conversations as unified or not, depending on eg.: how well do I know the context, or whether the OP is a person known for cross-posting (and to where), while at the same time not forcing everyone else to have their culture of conversation subsumed into essentially an attempt to make topical subreddits.

    Finally someone who gets it. This "problem" is in fact a total non-issue. Different groups talk about the same thing all the time. This is good, not bad.

  • Fediverse projects are maturing and adoption of them is trending up. I'm excited for the further development of the underlying technologies as well as the apps being built to leverage those technologies into even more integrated, user-friendly experiences.

    With any developing tech, small annoyances are found and ultimately patched or worked around. It's to be expected that no user experience is ever perfect, even for matured ecosystems. Typically, some smaller annoyances are tolerated when balanced with the overall utility and usefulness of the tech.

    One of the issues I've noticed (and I'm sure I'm not the first or only), is that when posts are relevant enough that the OP decides to cross-post into multiple communities, the comments and engagement stays with each community post leading to separate conversations.

    The existance of separate conversations itself isn't necessarily a bad thing. Maybe you post a recipe for Pot Roast in a general cooking community and also a community that helps refine recipes to improve them. It may be that the two separate conversations make more sense as the nature of discourse is focused on two different aspects of the content posted. If they were combined, it would be more difficult to sift through chatter to get at the discussion you were looking for.

    This concept is true for different communities as well as different instances. Maybe the Pot Roast recipe conversation generated on lemmy.carnivores is substantly different from the conversation at lemmy.vegan-curious and the existance of both is bolstered by the cultures and seneabilities of the different instance/communities. That could create usefull and/or thoughtful discourse that maybe wouldn't have happened if everyone was mixed together and talking past each other.

    However, there are plenty of informative posts attached to very similar communities on a given instance as well as posted to mirror-communities across separate instances. Each individual post is a separate entity and i find myself jumping in to different conversations of the same content to see what's being said in each. In addition to general replies often asking the same questions across all of the posts, unique engagement is diffuse and not connecting.

    I imagine that an OP would have trouble keeping up with all of these different interactions and likely defaulting to paying their attention to only one or two while the remaining posts are left to fend for themselves. Even if the OP stayed on top of them all, I assume they'd often have to answer the same questions multiple times.

    _The question I pose is: _

    What is the solution to myriad and diffuse conversations around cross-posts? Is there a way to handle this situation thru lemmy-ettiquette or does it require a technological solution?

    Maybe we handle it thru culture and expectation. If the decided upon method was to post once and then link that post to other communities for exposure, maybe that funnels everyone into one post to interact (when that's what OP wants).

    Is there a software solution on the app developer level that combines like posts together? Is it a protocol level solution thats required? Maybe something that allows a single post to essentially 'tag' different communities for exposure, while only posting once? Can we associate posts to an individual user rather than associating the post to a community, so all replies come to the user post rather than in a community?

    I don't know what the solution looks like and I'm not savvy enough to understand the protocol/software side to know if any of my examples are realistic. I also don't know if this is an issue for anyone else, or at least one that lemmy-ites actuallly care about enough to try and solve.

    Does anyone know if work is being done to address this? Am I focusing on something that is simply not a priority? I welcome your thoughts.

    ...I tried to choose what I thought was the best place for this post, but I'm open to moving it if I was in error. (Ironically, something that might be easier if posts were handled differently). :)

    What about making crossposts look like a quote post? Reddit already does that.

  • Fediverse projects are maturing and adoption of them is trending up. I'm excited for the further development of the underlying technologies as well as the apps being built to leverage those technologies into even more integrated, user-friendly experiences.

    With any developing tech, small annoyances are found and ultimately patched or worked around. It's to be expected that no user experience is ever perfect, even for matured ecosystems. Typically, some smaller annoyances are tolerated when balanced with the overall utility and usefulness of the tech.

    One of the issues I've noticed (and I'm sure I'm not the first or only), is that when posts are relevant enough that the OP decides to cross-post into multiple communities, the comments and engagement stays with each community post leading to separate conversations.

    The existance of separate conversations itself isn't necessarily a bad thing. Maybe you post a recipe for Pot Roast in a general cooking community and also a community that helps refine recipes to improve them. It may be that the two separate conversations make more sense as the nature of discourse is focused on two different aspects of the content posted. If they were combined, it would be more difficult to sift through chatter to get at the discussion you were looking for.

    This concept is true for different communities as well as different instances. Maybe the Pot Roast recipe conversation generated on lemmy.carnivores is substantly different from the conversation at lemmy.vegan-curious and the existance of both is bolstered by the cultures and seneabilities of the different instance/communities. That could create usefull and/or thoughtful discourse that maybe wouldn't have happened if everyone was mixed together and talking past each other.

    However, there are plenty of informative posts attached to very similar communities on a given instance as well as posted to mirror-communities across separate instances. Each individual post is a separate entity and i find myself jumping in to different conversations of the same content to see what's being said in each. In addition to general replies often asking the same questions across all of the posts, unique engagement is diffuse and not connecting.

    I imagine that an OP would have trouble keeping up with all of these different interactions and likely defaulting to paying their attention to only one or two while the remaining posts are left to fend for themselves. Even if the OP stayed on top of them all, I assume they'd often have to answer the same questions multiple times.

    _The question I pose is: _

    What is the solution to myriad and diffuse conversations around cross-posts? Is there a way to handle this situation thru lemmy-ettiquette or does it require a technological solution?

    Maybe we handle it thru culture and expectation. If the decided upon method was to post once and then link that post to other communities for exposure, maybe that funnels everyone into one post to interact (when that's what OP wants).

    Is there a software solution on the app developer level that combines like posts together? Is it a protocol level solution thats required? Maybe something that allows a single post to essentially 'tag' different communities for exposure, while only posting once? Can we associate posts to an individual user rather than associating the post to a community, so all replies come to the user post rather than in a community?

    I don't know what the solution looks like and I'm not savvy enough to understand the protocol/software side to know if any of my examples are realistic. I also don't know if this is an issue for anyone else, or at least one that lemmy-ites actuallly care about enough to try and solve.

    Does anyone know if work is being done to address this? Am I focusing on something that is simply not a priority? I welcome your thoughts.

    ...I tried to choose what I thought was the best place for this post, but I'm open to moving it if I was in error. (Ironically, something that might be easier if posts were handled differently). :)

    What if a post was its own separate thing, detached from the communities. You then "attach" the post to one or more communities.

    When a user comments on a post, the comment "comes from community xyz" but all comments are attached to the post not the community.

    Lemmy applications can choose to filter comments from one or more communities or show them all.

  • Piefed groups comment boxes from crossposts into one post. So no matter which crosspost you're looking at, you'll see all responses.

    This kinda erodes cultural differences between different communities though. Different communities may have very different approaches on how to talk about a post. I feel like this approach just leads to monoculturism.


Gli ultimi otto messaggi ricevuti dalla Federazione
  • > If it's some automated feature, I don't think it should be in the source property of the federated JSON in the first place.

    Thanks, it's this.

    Edit: oh interesting, I looked into it. We serve the absolute URL in HTML but not in markdown. I had no idea threadiverse apps read the markdown. Neat!

    read more

  • Not sure if you're already aware, but that relative link there is broken in Lemmy, Mbin, and Piefed.

    If you used it manually, I'd suggest not using relative links in posts targeted at users from software that hasn't implemented them yet.

    If it's some automated feature, I don't think it should be in the source property of the federated JSON in the first place.

    read more

  • @rekall_incorporated@piefed.social said in [Fediverse wide cross-instance / cross-platform link substitution [UX improvement thoughts]](/post/https%3A%2F%2Fpiefed.social%2Fc%2Ffediverse%2Fp%2F1568622%2Ffediverse-wide-cross-instance-cross-platform-link-substitution-ux-improvement-thoughts):
    > This issue is unresolved in Lemmy, but the Lemmy brand is permanently tainted among users who are looking for alternatives to American oligarchic technology services. The low moral standards of the Lemmy devs' (support for the brutal North Korean regime, promotion of russian propaganda narratives that they know are false) is a massive turn off for the exact target market of the Fediverse. It's a fact that many Europeans looking for alternatives instinctively recognize the demagoguery of the Lemmy devs and their fans.

    I don't think this is true at all.

    The average user doesn't know what Lemmy is, let alone the political views of their core development team.

    But don't worry, it's like that joke about vegans:

    How do you know the Lemmy devs are politically dubious? Don't worry, someone on the threadiverse will tell you.

    read more

  • How the links act is different from client to client. If you click the link in the Lemmy web UI, it will take you directly to Lemmy.wtf, but if you used Voyager (iOS client), it will automatically redirect to your own instance.

    This is something that should be built into the Lemmy web UI.

    You can also use browser addons. I have an addon that redirects me to my own instance, if I click on a link in my browser. I also have an addon that takes me from YouTube to Peertube, if the video also exist in PeerTube or if I click a PeerTube link, it takes me to my instance.

    Also how dare you criticise the awesome TLD .wtf, which is clearly an abbreviation of “What The Fediverse”?!

    read more

  • I've seen that being used. It works fine for more technical users, but it's just an extra pain point.

    If you make links, you need to apply the service Different UI from whatever instance/client/platform that you are using.

    I much prefer Piefed's soon to be released link substitution feature.

    read more

  • Mbin has had that feature for a while too

    read more

  • It's a temporary workaround but the experience is still clunky

    read more

  • Well; atleast for lemmy, there's https://lemmyverse.link/ ; which fixes exactly what you mention. You send that link, other people choose their instance in the redirect, and boom!

    read more
Post suggeriti
  • 0 Votes
    1 Posts
    0 Views
    Fedify 1.10.0: Observability foundations for the future debug dashboard Fedify is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities. We're excited to announce #Fedify 1.10.0, a focused release that lays critical groundwork for future debugging and observability features. Released on December 24, 2025, this version introduces infrastructure improvements that will enable the upcoming debug dashboard while maintaining full backward compatibility with existing Fedify applications. This release represents a transitional step toward Fedify 2.0.0, introducing optional capabilities that will become standard in the next major version. The changes focus on enabling richer observability through OpenTelemetry enhancements and adding prefix scanning capabilities to the key–value store interface. Enhanced OpenTelemetry instrumentation Fedify 1.10.0 significantly expands OpenTelemetry instrumentation with span events that capture detailed ActivityPub data. These enhancements enable richer observability and debugging capabilities without relying solely on span attributes, which are limited to primitive values. The new span events provide complete activity payloads and verification status, making it possible to build comprehensive debugging tools that show the full context of federation operations: activitypub.activity.received event on activitypub.inbox span — records the full activity JSON, verification status (activity verified, HTTP signatures verified, Linked Data signatures verified), and actor information activitypub.activity.sent event on activitypub.send_activity span — records the full activity JSON and target inbox URL activitypub.object.fetched event on activitypub.lookup_object span — records the fetched object's type and complete JSON-LD representation Additionally, Fedify now instruments previously uncovered operations: activitypub.fetch_document span for document loader operations, tracking URL fetching, HTTP redirects, and final document URLs activitypub.verify_key_ownership span for cryptographic key ownership verification, recording actor ID, key ID, verification result, and the verification method used These instrumentation improvements emerged from work on issue #234 (Real-time ActivityPub debug dashboard). Rather than introducing a custom observer interface as originally proposed in #323, we leveraged Fedify's existing OpenTelemetry infrastructure to capture rich federation data through span events. This approach provides a standards-based foundation that's composable with existing observability tools like Jaeger, Zipkin, and Grafana Tempo. Distributed trace storage with FedifySpanExporter Building on the enhanced instrumentation, Fedify 1.10.0 introduces FedifySpanExporter, a new OpenTelemetry SpanExporter that persists ActivityPub activity traces to a KvStore. This enables distributed tracing support across multiple nodes in a Fedify deployment, which is essential for building debug dashboards that can show complete request flows across web servers and background workers. The new @fedify/fedify/otel module provides the following types and interfaces: import { MemoryKvStore } from "@fedify/fedify"; import { FedifySpanExporter } from "@fedify/fedify/otel"; import { BasicTracerProvider, SimpleSpanProcessor, } from "@opentelemetry/sdk-trace-base"; const kv = new MemoryKvStore(); const exporter = new FedifySpanExporter(kv, { ttl: Temporal.Duration.from({ hours: 1 }), }); const provider = new BasicTracerProvider(); provider.addSpanProcessor(new SimpleSpanProcessor(exporter)); The stored traces can be queried for display in debugging interfaces: // Get all activities for a specific trace const activities = await exporter.getActivitiesByTraceId(traceId); // Get recent traces with summary information const recentTraces = await exporter.getRecentTraces({ limit: 100 }); The exporter supports two storage strategies depending on the KvStore capabilities. When the list() method is available (preferred), it stores individual records with keys like [prefix, traceId, spanId]. When only cas() is available, it uses compare-and-swap operations to append records to arrays stored per trace. This infrastructure provides the foundation for implementing a comprehensive debug dashboard as a custom SpanExporter, as outlined in the updated implementation plan for issue #234. Optional list() method for KvStore interface Fedify 1.10.0 adds an optional list() method to the KvStore interface for enumerating entries by key prefix. This method enables efficient prefix scanning, which is useful for implementing features like distributed trace storage, cache invalidation by prefix, and listing related entries. interface KvStore { // ... existing methods list?(prefix?: KvKey): AsyncIterable<KvStoreListEntry>; } When the prefix parameter is omitted or empty, list() returns all entries in the store. This is useful for debugging and administrative purposes. All official KvStore implementations have been updated to support this method: MemoryKvStore — filters in-memory keys by prefix SqliteKvStore — uses LIKE query with JSON key pattern PostgresKvStore — uses array slice comparison RedisKvStore — uses SCAN with pattern matching and key deserialization DenoKvStore — delegates to Deno KV's built-in list() API WorkersKvStore — uses Cloudflare Workers KV list() with JSON key prefix pattern While list() is currently optional to give existing custom KvStore implementations time to add support, it will become a required method in Fedify 2.0.0 (tracked in issue #499). This migration path allows implementers to gradually adopt the new capability throughout the 1.x release cycle. The addition of list() support was implemented in pull request #500, which also included the setup of proper testing infrastructure for WorkersKvStore using Vitest with @cloudflare/vitest-pool-workers. NestJS 11 and Express 5 support Thanks to a contribution from Cho Hasang (@crohasang@hackers.pub), the @fedify/nestjs package now supports NestJS 11 environments that use Express 5. The peer dependency range for Express has been widened to ^4.0.0 || ^5.0.0, eliminating peer dependency conflicts in modern NestJS projects while maintaining backward compatibility with Express 4. This change, implemented in pull request #493, keeps the workspace catalog pinned to Express 4 for internal development and test stability while allowing Express 5 in consuming applications. What's next Fedify 1.10.0 serves as a stepping stone toward the upcoming 2.0.0 release. The optional list() method introduced in this version will become required in 2.0.0, simplifying the interface contract and allowing Fedify internals to rely on prefix scanning being universally available. The enhanced #OpenTelemetry instrumentation and FedifySpanExporter provide the foundation for implementing the debug dashboard proposed in issue #234. The next steps include building the web dashboard UI with real-time activity lists, filtering, and JSON inspection capabilities—all as a separate package that leverages the standards-based observability infrastructure introduced in this release. Depending on the development timeline and feature priorities, there may be additional 1.x releases before the 2.0.0 migration. For developers building custom KvStore implementations, now is the time to add list() support to prepare for the eventual 2.0.0 upgrade. The implementation patterns used in the official backends provide clear guidance for various storage strategies. Acknowledgments Special thanks to Cho Hasang (@crohasang@hackers.pub) for the NestJS 11 compatibility improvements, and to all community members who provided feedback and testing for the new observability features. For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository. #fedidev #release
  • 0 Votes
    1 Posts
    5 Views
    The problem with #ActivityPub and the #fediverse is not enough people are posting bangers
  • 0 Votes
    1 Posts
    16 Views
    Vacations are wonderful. It is a privilege to be able to travel without worry. It's also wonderful to be home, and to have the time to work on projects I care about. With those thoughts in mind, I present release v3.1.1 of Ktistec, an ActivityPub server written in the Crystal programming language!This release is a mixed bag of small features and improvements:AddedAuto-link URLs in posts. (fixes #24)Support searching by actor username. (fixes #102)Support hourly granularity in metrics charts.FixedMark actor as down if refresh fails.Remove draft posts from the everything collection.Ignore charts with no points in the date range.Ensure HTTP::Client instances are closed.I added support for multiple users at the beginning of the month. I'm very interested in feedback on how that's working out for anyone using it.#ktistec #fediverse #activitypub #crystallang
  • 0 Votes
    1 Posts
    9 Views
    We’ve just added new profile tags ✨👑 Administrator and 🛡️ Moderator tags are now displayed on user profiles.💎 Supporter (available to our wonderful patrons) can now be enabled in account settings if you’d like to show your support publicly. Your choice, your profile 💫Thank you for helping us keep Vernissage growing!#Vernissage #Fediverse #PhotoSharing #OpenSource #Update