crossposted from: https://jlai.lu/post/15932635

Hey everyone!

I hope this post does not break the rules, last year I ran Lemmyvision a song contest on Lemmy, and I'm excited to announce that the second edition is now live!

For those not in the loop, here's how it works:

TL;DR

• From right now and until April 1st, discuss with your country’s community on Lemmy about which song to send to the contest.
• Submit the song in this community by makign a new thread.
• On April 2nd, voting will begin, where you will rank your favourite songs in a form. Any song not submitted by this date will not be featured.
• On April 8th, results of everyone’s favourite songs will be published.
• You can use !lemmyvision@jlai.lu for any question, this will be the community for updates and results, make sure to subscribe if you’d like to stay in the loop.

You can find all the information needed on this post : https://jlai.lu/post/15932635

Cheers!

The Funkwhale music platform is alive and in active development, and they're working on a feature to filter far-right artists off the network. Some Fediverse self-hosters are divided on letting a third party decide what should be allowed in their library.

La parola hacking da qualche tempo va di moda per l’incremento di attacchi informatici, che stanno avvenendo in tutto il mondo. A parte rari casi, si pensa che sia un fenomeno nato e cresciuto recentemente. In realtà affonda le sue origini già dal 1878. Engineering & Technology ha illustrato una breve panoramica di come sono nate e si sono sviluppate queste pratiche, nel corso dei secoli. I primi episodi ci sono stati a partire dall’invenzione del telefono. All’inizio i centralinisti erano giovani ragazzi, in quanto avevano già operato con i telegrafi. Questi, però si divertivano a fare scherzi e a capire più come funzionasse il sistema che a lavorare. Tanto che nel 1878 la Bell dovette cacciarne un gruppo da New York per aver ripetutamente e intenzionalmente scollegato conversazioni e collegato utenti sbagliati per gioco. Da allora la compagnia assunse solo impiegate donne per quel ruolo. Il secondo caso della storia hacking si ebbe dopo la scoperta delle onde elettromagnetiche alla fine del 19esimo secolo. Questa pavimentò la strada per il telegrafo senza fili di Guglielmo Marconi. Nel 1903 il mago e inventore Nevil Maskelyne sabotò la prima dimostrazione pubblica di John Ambrose Fleming della tecnologia “sicura” dell’apparecchio inventato da Marconi. Lo fece inviando messaggi in codice Morse che screditavano il sistema. A seguito di ciò, Fleming inviò una lettera al Times in cui chiedeva aiuto ai lettori per smascherare il colpevole del gesto. Maskelyne rispose affermando che il suo era stato un gesto per rivelare la vulnerabilità del telegrafo senza fili. La parola “hacker” ha origini antiche e, inizialmente, non aveva alcuna connotazione negativa. Nei primi anni del XX secolo, il termine si riferiva a qualcuno capace di trovare soluzioni innovative a problemi tecnici. È negli anni Sessanta, al Massachusetts Institute of Technology (MIT), che il termine “hacker” si lega al mondo dell’informatica. Qui, un gruppo di giovani programmatori e tecnologi appartenenti al Tech Model Railroad Club (TMRC) iniziò a smanettare con i primi computer disponibili, come il PDP-1, cercando modi creativi per utilizzare le macchine al di là delle loro intenzioni originali. Non era una questione di distruzione, ma di esplorazione: per gli hacker del tempo, la tecnologia rappresentava un terreno di gioco da comprendere e sfruttare al massimo. In questa fase, gli hacker erano pionieri della conoscenza. Si prefiggevano di superare i limiti imposti dalla tecnologia, sfidando le convenzioni e migliorando i sistemi esistenti. Alcuni tra i primi “hack” documentati non riguardavano l’informatica come la intendiamo oggi, ma i sistemi telefonici. Negli anni Settanta, la “phreaking” – abbreviazione di “phone hacking” – divenne una delle prime forme di hacking digitale. Figure come John Draper, conosciuto come “Capitan Crunch”, scoprirono che soffiando in un telefono con un fischietto incluso in una scatola di cereali si poteva manipolare la rete telefonica AT&T per effettuare chiamate gratuite. Questo tipo di hacking era visto come un atto di ribellione contro il sistema, ma anche come un’opportunità per sperimentare. Con l’avvento dei personal computer negli anni Settanta, l’hacking si spostò rapidamente dai sistemi telefonici ai computer veri e propri. La comparsa del MITS Altair 8800 nel 1975 e, successivamente, dell’Apple I e II, segnò un punto di svolta. Era l’epoca dei computer a scheda singola, con capacità limitate ma sufficienti per affascinare menti curiose. Gruppi di appassionati si riunivano nei cosiddetti “computer club”, come l’Homebrew Computer Club in California, dove figure come Steve Wozniak e Steve Jobs iniziavano a plasmare il futuro dell’informatica. In questo contesto, gli hacker erano ancora principalmente esploratori e inventori. Tuttavia, la comparsa delle prime reti – come ARPANET, il predecessore di Internet – creò nuove opportunità per il loro operato. Alcuni hacker iniziarono a infiltrarsi nei sistemi non per danneggiarli, ma per studiarli. Un esempio è Kevin Mitnick, uno dei primi hacker celebri, che negli anni Ottanta diventò noto per le sue intrusioni nei sistemi di telecomunicazione e informatici. Mitnick rappresentava il perfetto esempio di un hacker che univa competenze tecniche a un’incredibile abilità nel social engineering, convincendo le persone a rivelare informazioni sensibili. Tra i primi attacchi informatici documentati ci fu il “Morris Worm” del 1988, considerato il primo worm diffuso su larga scala. Creato da Robert Tappan Morris, un ricercatore della Cornell University, il worm non era stato progettato per causare danni, ma per esplorare l’ecosistema di ARPANET. Tuttavia, un errore nel codice fece sì che il worm si replicasse in modo incontrollato, paralizzando migliaia di computer. Questo evento segnò un punto di svolta, dimostrando che i sistemi interconnessi potevano essere vulnerabili a livello globale. Negli stessi anni, altri hacker come Gary McKinnon si distinguevano per i loro attacchi mirati. McKinnon, conosciuto come “Solo”, riuscì a penetrare nei sistemi della NASA e del Dipartimento della Difesa degli Stati Uniti all’inizio degli anni Duemila. Le sue motivazioni, dichiarate in seguito, erano legate alla ricerca di prove sull’esistenza di tecnologie aliene e UFO. McKinnon portò alla luce il concetto di hacker etico o idealista, qualcuno che utilizza le proprie abilità non per guadagno personale, ma per una causa. Negli anni Novanta, con la diffusione di Internet, l’hacking cambiò volto. La comunità hacker si divise: da un lato c’erano i “white hat” (cappelli bianchi), hacker etici che lavoravano per migliorare la sicurezza dei sistemi; dall’altro, i “black hat” (cappelli neri), individui o gruppi motivati da interessi personali, economici o criminali. Fu in questo periodo che nacquero i primi virus informatici progettati per danneggiare i sistemi, come “Michelangelo”, che colpì centinaia di migliaia di computer nel 1992. Un altro esempio di attacco significativo fu quello del gruppo hacker “L0pht”, che nel 1998 testimoniò davanti al Congresso degli Stati Uniti avvertendo che l’intero Internet poteva essere paralizzato in soli 30 minuti. Questo gruppo di hacker etici, pur non avendo intenzioni malevole, dimostrò quanto le infrastrutture informatiche fossero fragili e vulnerabili. Con il nuovo millennio, l’hacking si è evoluto in una vera e propria industria. Gli attacchi informatici non sono più frutto di singoli individui, ma spesso vengono condotti da organizzazioni strutturate, talvolta supportate da governi. Il fenomeno del ransomware, emerso in modo dirompente con attacchi come quello di WannaCry nel 2017, ha dimostrato come l’hacking sia diventato una minaccia economica globale. I cybercriminali moderni mirano a rubare dati sensibili, estorcere denaro o influenzare intere economie. Parallelamente, sono emersi gruppi di hacker come Anonymous, che combinano hacktivismo e attacchi mirati per promuovere cause politiche. Questi gruppi hanno colpito governi, multinazionali e organizzazioni religiose, utilizzando metodi come il DDoS per interrompere i servizi. La storia degli hacker è una storia di creatività, ribellione e innovazione. Da pionieri che esploravano i primi computer a gruppi organizzati che sfruttano le vulnerabilità dei sistemi globali, gli hacker hanno plasmato il mondo digitale come lo conosciamo oggi. La loro evoluzione continua, spingendo governi e aziende a sviluppare tecnologie sempre più sofisticate per proteggere dati e infrastrutture. Tuttavia, l’essenza dell’hacking rimane la stessa: una sfida costante ai limiti della tecnologia, con conseguenze che possono essere tanto costruttive quanto distruttive.

The foundation will focus on improving ActivityPub and the user experience, informing policymakers, and educating people about the fediverse and how they can participate. They currently have some backing from Meta, Flipboard, Ghost, Mastodon, and others, and the Ford Foundation has also offered the organization a large grant to get the project started. In total, SWF is closing in on $1 million in financial support (or was, as of September) (from TechCrunch)

cross-posted from: https://lemmy.ca/post/39653865

It's brief, around 25:15

https://youtube.com/watch?v=nf7XHR3EVHo

If you've been sitting on making a post about your favorite instance, this could be a good opportunity to do so.

Going by our registration applications, a lot of people are learning about the fediverse for the first time and they're excited about the idea. I've really enjoyed reading through them :)

We Distribute is a community-organized news site which covers the Fediverse. If you like to write about federated social media then you could help to expand their coverage.

See the link above for more details.

On the meta update, a previous admin was able to get the hexbear.net domain back, and we were able to established shared access. We are thankful for everything that they have done as this site would not exist without them, with this shared access the stress of site administration has been lessened.

This might be dumb, and someone's probably already working on this but it's late and this is just a bugbear I have to get out of my head so I can sleep.

This is a basic outline of the concept of an open‐source federated gaming platform—a decentralized alternative to traditional centralised platforms like Steam.

Fediverse Gaming: Decentralizing Game Distribution, Advertising, and Community Engagement

Abstract

Centralized gaming platforms like Valve's Steam, Blizzard's Battle.Net, Epic Game Store and even GOG ensure that there must always be a singular power who gets rich not from making games but by controlling and exploiting the market. Fediverse Gaming proposes an open-source, federated platform that empowers developers and publishers to host their own game distribution and community hubs. By leveraging the ActivityPub protocol, the open-source platform enables independent instances for selling games, game items, and hosting communities while addressing longstanding concerns over high platform fees, exorbitant advertising costs, and expensive featured placements. In addition, users can post buyer reviews that are shared across instances, fostering transparent and organic community feedback. This decentralization liberates developers from the high fees imposed by centralized platforms, cutting out wasteful middle-men and redefining how games reach their audiences.

1. Introduction

Centralized gaming platforms like Steam have long controlled not only game distribution but also the economic dynamics that shape a game’s visibility and profitability. Developers and publishers must contend with steep platform fees, as well as additional costs for advertising and securing featured placements. Fediverse Gaming aims to disrupt this model by decentralizing game hosting, sales, and community management—offering a transparent, cost-effective alternative that in combination with user communities and reviews build trust and drive organic discovery.

2. Background and Motivation

2.1 Current Centralized Model

• High Platform Fees: Centralized platforms impose substantial fees on game sales, often taking a significant percentage of revenue. This not only affects margins for developers and publishers but also creates a financial barrier to entry for smaller or independent creators.
• Advertising and Featured Fees: Beyond the basic platform fees, developers face additional costs to secure prominent advertising space or to be featured on the platform. These extra charges often skew market exposure in favor of those who can afford high promotional fees.
• Monetization Constraints: The combination of high platform fees and costly promotional expenses means that a significant portion of a game’s revenue is siphoned off by intermediaries, reducing the profitability for creators.

2.2 The Promise of Federation

• Decentralization of Control: A federated model distributes hosting and community management across independent instances, enabling developers to regain control over how their games are promoted and monetized.
• ActivityPub Integration: Leveraging ActivityPub allows for seamless communication between instances. This not only facilitates federated community interactions but also powers a dedicated system for sharing buyer reviews across the network.
• Empowering Stakeholders: By hosting their own instances, developers and publishers can bypass the high fees imposed by centralized platforms, tailor their advertising strategies, and engage directly with their audience.

3. Problem Statement

Developers and publishers face significant hurdles in the current ecosystem:

• Exorbitant Platform Fees: Centralized platforms take a large cut of revenue, leaving less profit for developers and publishers.
• High Advertising Costs: Securing advertising space and featured placements requires additional fees that further erode revenue.
• Fragmented Feedback Channels: Buyer reviews are often siloed within proprietary systems, limiting transparent, cross-community feedback and organic discovery.

4. Proposed Solution: Fediverse Gaming

Fediverse Gaming is designed as an open-source, decentralized platform addressing these challenges through the following core components:

• Federated Instances: Each developer or publisher can deploy an independent node that hosts games, game items, and community features. This autonomy allows for direct control over both distribution and promotion.
• Transparent Fee Structures: By eliminating the middleman, the platform minimizes platform fees and allows developers to set their own pricing and advertising strategies without hidden costs.
• ActivityPub Integration: Facilitates cross-instance communication for community interactions and powers a federated review system, ensuring that buyer reviews are shared network-wide.
• Integrated Storefront: A modular marketplace that manages game listings, secure transactions, and transparent advertising placements—all without the heavy fees of centralized systems.
• Cloud Save Services: A decentralized cloud save solution ensures that player progress is securely stored and accessible across federated servers.
• Review Aggregation Module: Enables buyers to post game reviews locally which are then disseminated across the network, enhancing community trust and aiding organic game discovery.
• Developer/Publisher Dashboard: Provides tools for uploading games, managing advertising space (including options for featured placements), tracking sales, and monitoring promotional performance.

5. System Architecture and Technical Design

5.1 Core Components

• Instance Server: Serves as the backbone for each federated node, managing user authentication, content management, and inter-instance communication.
• Storefront Module: Handles game listings, Lago transactions, and advertising placements, allowing developers to manage fees transparently.
• ActivityPub Integration Layer: Ensures seamless interaction between nodes, enabling community engagement and the sharing of buyer reviews.
• Review Aggregation Module: Collects and distributes buyer reviews from local instances across the entire network, promoting transparency.
• Cloud Save Infrastructure: Uses distributed storage solutions to secure player data across federated servers.
• Developer/Publisher Dashboard: Offers a centralized interface for managing game content, advertising space, fee structures, sales analytics, and community feedback.

5.2 Federation Protocol and Security

• Interoperability: Utilizing ActivityPub guarantees that users across different instances can interact, follow updates, and participate in community discussions, including sharing reviews.
• Security Measures: Regular open-source audits, decentralized identity management, and robust encryption protocols will be implemented to secure data and transactions.
• Scalability: The architecture is designed for horizontal scaling, ensuring that each instance can handle increased loads as the network grows.

6. Minimum Viable Product (MVP) Specifications

To validate the concept and enable iterative development, the MVP should include:

• Federated Instance Deployment: A basic server setup with user registration, profile management, and instance configuration.
• Core ActivityPub Functionality: Fundamental integration to support cross-instance interactions, including posting, commenting, and federated sharing of buyer reviews.
• Digital Storefront: A minimal e-commerce system supporting game listings, transaction processing, and transparent advertising management.
• Cloud Saves: Initial integration of cloud storage to securely backup player progress.
• Developer/Publisher Dashboard: Tools for uploading games, managing advertising and featured placements, tracking sales, and monitoring fee structures.
• Review Aggregation Module: A system enabling buyers to submit game reviews locally, which are then federated across instances via ActivityPub.
• Documentation and API Endpoints: Comprehensive documentation and APIs to facilitate third-party integrations and future expansion.

7. Benefits to Developers and Publishers

7.1 Cost Efficiency and Fee Transparency

• No More Platform Fees: By eliminating centralized intermediaries, developers retain a larger share of their revenue, avoiding the high cuts imposed by traditional platforms.
• Reduced Advertising Costs: Developers can manage their own advertising and featured placements, setting transparent and competitive pricing models without hidden fees.
• Direct Financial Control: Independent instance hosting allows for complete oversight of fee structures, reducing dependence on opaque centralized policies.

7.2 Enhanced Community Feedback

• Federated Game Reviews: A network-wide review system provides comprehensive, transparent feedback from buyers, improving trust and aiding organic discovery.
• Direct Audience Engagement: Developers can interact directly with their users, gaining real-time insights and feedback without intermediaries.

7.3 Innovation and Flexibility

• Modular Architecture: The platform’s design supports the seamless integration of new features—ranging from advanced advertising analytics to enhanced review moderation tools.
• Interoperability: Federation across the network encourages collaboration, cross-promotion, and community growth among independent developers and publishers.

8. Development Roadmap and Future Work

Phase 1: Planning and Prototyping

• Finalize the architecture design with an emphasis on transparent fee management, advertising integration, and review federation.
• Develop initial prototypes for federated instance deployment and ActivityPub integration, including a basic review aggregation module.
• Engage early adopters to gather feedback on fee structures, advertising models, and review functionalities.

Phase 2: MVP Development

• Build core modules: instance server, storefront, review aggregation, cloud save integration, and developer dashboard.
• Conduct testing focusing on cost transparency, transaction handling, and review dissemination.
• Publish initial documentation and developer APIs for community contributions.

Phase 3: Beta Release

• Launch a public beta with select developers and publishers.
• Monitor performance and gather feedback on costs, advertising effectiveness, and review functionalities.
• Refine core features based on user input and performance analytics.

Phase 4: Full Launch and Expansion

• Officially release the platform with comprehensive documentation, support channels, and community forums.
• Explore advanced features such as multi-currency support, patch support, speed improvements, game lists such as best reviewed, top sellers, and new and upcoming lists, and add more sophisticated review moderation.
• Foster a community-driven ecosystem for ongoing innovation and continuous improvements in decentralized game hosting.

9. Challenges and Mitigation Strategies

• Technical Complexity: Integrating a robust federated system with transparent fee management, e-commerce, and review sharing requires thorough planning and extensive testing.
  Mitigation: Utilize modular design principles and proven protocols like ActivityPub and Lago to ensure smooth operations across instances.
• Adoption Barriers: Convincing developers to transition from established, centralized fee structures may be challenging.
  Mitigation: Highlight the financial and operational benefits, such as lower hosting fees and reduced advertising costs, while demonstrating the value of direct community engagement. This may be appealing to indie developers burned in the recent mass layoffs by the monopolies.
• Consistency in Review Aggregation: Ensuring that game reviews are accurately shared and moderated across decentralized nodes can be complex.
  Mitigation: Develop robust algorithms and community guidelines for review aggregation and moderation, with input from early adopters.

10. Conclusion

By decentralizing game hosting, advertising, and review aggregation, the platform empowers developers and publishers to regain control over their financial outcomes and promotional strategies. With transparent fee structures that alleviate high platform and advertising costs, coupled with a federated review system that amplifies buyer feedback, Fediverse Gaming paves the way for a more equitable, innovative, and community-driven marketplace. Stakeholders are invited to collaborate in shaping this next-generation ecosystem for independent game distribution and promotion.

This outlines the vision, design, MVP specifications, and strategic benefits of Fediverse Gaming—positioning it as a compelling alternative for developers and publishers seeking greater financial control, reduced fees, and enhanced community engagement in the competitive gaming ecosystem.

cross-posted from: https://lemm.ee/post/56496251

I'd like to add to suggest a couple of things regarding Mastodon and user onboarding/retention.

The Server Selection Problem^TM^

The single biggest problem with Mastodon adoption is the fact people see talk about a server and give up. As such, servers need to be removed from the conversation and onboarding process. A server still needs to be selected for a new user, however, which raises the question: How should we select a server for a new user?

The obvious solution is to simply direct users to mastodon.social, which is actually what Mastodon already does to a certain extent. The issue with this is that the Fediverse is meant to be decentralized. As such, it's counterproductive to funnel people towards a single server. This causes maintenance bottlenecks and privacy/data-protection concerns.

As such, there needs to be some sort of method that ranks servers based on a few factors in order to select the optimal server for any given user, while keeping the decentralized nature of the Fediverse in mind.

Why any server?

First, it's important to answer the question of why would any given user pick any given server.

Generally speaking, the server isn't a big deal, as in, any server allows users to interact with the whole of the network in its full capacity.

All servers are Mastodon, after all.

However, there are differences. The most significant ones are, I'd say: location, uptime, and language.

A user benefits from being registered to a server that's geographically close to them, as that leads to a better connection. Additionally, servers with high uptime and stability are preferred, as users may have different times they use the server and nobody likes to try and access a server and see that it's down for any number of reasons. Finally, users need to be able to understand the language the server is in (obviously).

I believe these three factors should be at the forefront of the decision-making process for deciding what server to be suggested to any given user on sign-up.

Auto-selector

With that, comes the solution: a server auto-selector. A game I play, DCSS, actually does something similar for online play.

(I have my location turned off and there are very few servers, as you can see, so listing them is trivial.)

This isn't exactly a novel scientific breakthrough, but I think it's a significant notion for helping the onboarding process for new Mastodon users.

A server auto-selector should filter servers to suggest by following these steps:

• Detect the user's system language.
• Detect the user's location.
• Calculate the server's uptime score.
• Pseudo-rank user-count.

I believe the first two points are self-explanatory. Being that Mastodon (and the Fediverse, in general) stands firmly against data-harvesting, location data should probably not be mandatorily collected. It should be easy to either ask the user for some vague information or simply allow them to skip this step entirely, even if it might affect the user experience. Additionally, there's the issue that many servers don't make it known where they're hosted. Ideally, this could change to facilitate server selection for the users, but there's always the point that, if a server doesn't say where it's hosted, it gets pulled down by the algorithm, which in turn encourages divulging that kind of information; this might a problem solved by the solution, if you get my meaning.

What I mean by uptime score is simply an evaluation of the server's uptime history. For example, it's not good policy to direct users towards servers that are often unavailable, it might be disadvantageous to direct users to servers with too-frequent downtime for maintenance, and so on. As such, the server auto-selector should calculate a sort of "score" for any server that fits the first two points. I can't say how this should be calculated, exactly, but I'm sure some computer-knowers out there can come up with a less-than-terrible methodology for this.

The last point is something that I think should be taken into account as well, regarding the user-count of the servers. As I mentioned, we can't funnel users towards a single server, but another issue is that we should actually encourage user dispersion over many servers. The outlined method might already do this to a sufficient extent, but I suggest doing some sort of randomization of filtered servers based on user-count. I think it's wrong to simply plug a new user into the least-populated server around, but I do think that over-populated servers, in a relative sense, should be discouraged by the server-selector.

Worst case scenario, a random server that passes the uptime score point can be selected for any new user.

The onboarding experience

Basically, this should be as simple as possible. The more questions need to be answered, the worse.

I think a simple "Join Mastodon" button is the best. Just a big blue button in the middle of the homepage.

Server selection should start as soon as the new user accesses the joinmastodon website, and clicking the button simply redirects the user to the sign-up process for that server.

I believe this approach would increase adoption of Mastodon by streamlining the server selection process, as well as help the continuous decentralization of the Fediverse.

The Feed Problem

Another significant issue with Mastodon is the feed and community/discovery aspects.

Creating a new Mastodon account yields... Nothing. An empty feed!

This is absolutely terrible and ruins user retention. I've had several people tell me that this first-experience emptiness completely turned them off from Mastodon. It's not intuitive, and it needs to be corrected.

A simple solution

Mastodon does have feeds, but they're all tucked away in the Explore and Live Feeds tabs.

I think the single biggest change that Mastodon can make, as far as this goes, is to shift the Explore->Posts feed to the Home tab. Just do it like Twitter or Bluesky, make the discovery feed the first thing a new user encounters.

That, by itself, should make a difference in terms of user retention.

---

Maybe I'm delusional and severely underestimating how doable this is, but I really believe Mastodon needs to change the way it deals with new users if we want it to actually grow into a strong social media, keyword social (it needs people).

Thoughts?

Ibis is a federated encyclopedia which uses the ActivityPub protocol, just like Mastodon or Lemmy. If you want to start a wiki for a TV series, a videogame, or an open source project then Ibis is for you! You can register on an existing instance or install it on your own server. Then you can start editing on the topic of your choice, and connect to other Ibis instances for different topics. Federation ensures that articles get mirrored across many servers, and can be read even if the original instance goes down. Ibis is written in Rust and Webassembly, fully open source to make future enshittification impossible.

This release features a redesigned explore page to browse instances and recently edited articles. Articles now have federated, nested comments, as well as more subscription options to get notified about new edits and comments. There are also lots of minor changes and improvements.

Changelog

• New explore page with list of instances which shows the topic, update time and list of recently edited articles
• Implement nested comments for articles
• Users can subscribe to articles, in order to get notified about new edits and comments
• Settings for instance name and topic
• Much better error handling
• Add HTML title tag for all pages
• Icons
• Make diff view readable in dark mode (thanks @Earthgames)
• Basic about page
• Show pending edits which have not federated yet
• Various bug fixes

The next major version 0.3.0 will include federation with Lemmy, Mastodon and other compatible Fediverse platforms. The plan is to treat each Ibis instance as a community, with articles as posts. This way users on Lemmy and compatible platforms can directly browse, read and comment on wiki articles.

To follow Ibis development subscribe to !ibis@lemmy.ml or join the Matrix chat. Contributions to the source code are more than welcome.

Maybe you've spent some time on a #Fediverse community server and enjoyed it, but really wanted to start your own. What do you need? How do you do it? We wrote a guide just for you.

This website is supposed to help visualize networks and communities on the fediverse.

The website does not appear to be working.

Their mastodon project page is also gone: https://mastodon.social/@fediversespace

Does anyone know of any alternatives?

The organization behind critical pieces of Trust & Safety infrastructure in the Fediverse is struggling to make ends meet. Here's what's going on, what the road ahead looks like, and how to help.

A podcast with a professor from Canada.

This is a pretty epic feature. I hope to see it in Lemmy too.

I'm trying to see if I can host my own Fediverse instance for friends and family and I want to know what kind of device would be required. I'm an absolute beginner to self-hosting so I was wondering if I can start cheap (Raspberry Pi 2GB RAM is something I can definitely consider).

Also, can one device host multiple software? Like if I wanted both a WordPress instance and a Hubzilla instance or a Matrix/XMPP instance

Sorry to ask a similar question compared to a week ago

How about a e-commerce site in the Fediverse where you can either sell second hand stuff (like ebay) or sell stuff you made or paid people make (like amazon or etsy) but with multiple instances with different moderation, shipment costs and some might require you to have id obviously their will be sketchy instances or users but the community could make a list of instances/users to avoid or to be careful of at least, and most the users on this list would be user who their instance hasn’t banned (which might put the instance into disrepute, since if they are notorious enough to land on this list you should probably ban them) and the people who are in charge of this list can get reports from user and they will have to conform from other buyers who bought from that individual to make sure people aren’t lying because they don’t like the person or something, it could be federated/integrated with services like mastodon, peertube and possibly lemmy where you can sign in with it with your account from these services, but you have to make an account with this service to actually sell anything, but user from these other platforms could link their shop on this service on their mastodon post and/or account and peertube videos/account (sorry if I got carried away), what do you guys think?

I'm looking to add a custom domain to my email to start building a more permanent identity on the internet (I have been shifting providers since I started degoogling).

I also want to either host a WordPress site or a fediverse instance (haven't decided) like Hubzilla for things like my writings and a general place to find my stuff online and maybe even host a few friends' pages.

Can I buy one domain and use it for both?

cross-posted from: https://lemmy.world/post/25243870

I recently started messing around with ActivityPub, Mastodon and Lemmy and created LemmyLink, an open-source bot that seamlessly bridges Reddit and Lemmy. Triggered by the phrase “LemmyLink!” in a Reddit post title, body, or comment, the bot automatically creates a corresponding post on your chosen Lemmy instance. This allows Bidirectional post and comments between Reddit and Lemmy by triggering a Reddit bot.

Feel free to play around with it on r/LemmyLink. Simply include "LemmyLink!" anywhere in your post title, body or comment on the LemmyLink sub. This is setup on my own Lemmy instance lemmylink.com currently not federated and marked as a bot to avoid spamming the Fediverse.

There are some pros and cons to bridging communities but I think if done with transparency and user opt-in it could serve as an interesting way to bring more users in to the Fediverse. But, I'm curious what others think.

How LemmyLink Works

Only works for Subreddits and Lemmy communities specified in the code Reddit users include "LemmyLink!" in their Reddit post or comment LemmyLink posts the Reddit comment or post to Lemmy LemmyLink responds to the Reddit post or comment with link back to the Lemmy post The code is rough so go easy on me but it is available on GitHub: https://github.com/ateames/LemmyLink

Feel free to fork it, suggest improvements, or simply try it out.

I used to just post on .world but disagree with some of their admin and mod policies so I try to post on .ml then cross post. Is it worth cross posting to even small instances or should I expect their users are on the bigger communities too? I don’t want to spam but only posting in .world misses the point of decentralization

Hello everyone,

Has anyone ever considered potentially building or launching a platform similar to the Internet Archive but using ActivityPub?

This could serve as a decentralized network to document, preserve, and protect online content from loss, censorship, and other threats, ensuring its availability for future generations.

For those unfamiliar, the Internet Archive is a non-profit that has been preserving digital media and promoting universal access to knowledge since 1996.

It’s famous for services like the Wayback Machine and Archive-It.

Given the importance of preserving digital heritage, especially in the context of censorship and data loss, a Fediverse-based equivalent could fill a crucial role.

The decentralized nature of ActivityPub could provide a robust alternative to centralized solutions.

I'd love to see this kind of project come to life, but, unfortunately, I lack the motivation, time, and energy to take it on alone.

Has anyone else ever considered something similar?

Are there any existing projects that might be interested in this direction?

Internet Archive Wikipedia

Radio Free Fedi was one of the greatest artist projects to ever hit the network. With an unprecedented ethos and a fanatical approach to building and supporting the music community, it became an institution. Today, we remember and honor RFF.