Acropolis is fairly similar to diaspora* at this stage with the key difference being that being managed via the Collective Code Construction Contract which prioritizes the community around software over the technicals. Sign up at https://dogieda.org if you want to try the early results.

🛠️ If administration is your thing, #YunoHost is the easiest way to install #Acropolis. Version 2021.12.02~ynh1 still requires initial account creation via web interface and promotion to admin via command line but in the near future, admin account creation will be more seamless. Link to install on your YunoHost box: https://install-app.yunohost.org/?app=acropolis

⚠️ Please report issues at https://github.com/YunoHost-Apps/acropolis_ynh/issues

  • @southerntofu
    link
    22 years ago

    Hello, that sounds cool! Could you explain what took you to Diaspora and not XMPP/ActivityPub? Do you intend to port the Diaspora s2s protocol to an established federation protocol?

    • weexOPM
      link
      32 years ago

      Great question. The story started earlier in the year when I started thinking more seriously about social media and what a better future for it might be. I came to the conclusion that nobody really knows so experimentation was key. This led to a survey and looking at which projects were popular and established enough to be a good platform for experimentation, and could also use more development energy. Mastodon and diaspora* were the best candidates.

      At that point, I realized it’s not only a problem of not knowing what better social media looks like, but that I don’t know how to run a successful open source software project. That’s when I found Pieter Hintjens and the Collective Code Construction Contract (C4) that he developed with the ZeroMQ community. The core idea there is that it is the community that is primary, not some codebase, or feature, or framework. Only with a strong community can software be developed and maintained long-term to meet the needs of the market.

      It’s at that point that c4social was formed (later becoming Magic Stone) and Mastodon was forked. Once we realized the job of maintaining a repo under our process isn’t too difficult, we decided to also fork diaspora*. C4 hasn’t been applied anything in social media so part of the opportunity for this community is to test whether it can work, and a good experiment is reproducible so two projects is better than one in this respect. Since then we’ve just been solving problems that come to us through using the software and from those who stumble upon posts like this. The community is small, growing nicely and starting to yield interesting results as far as the software goes.

      So that’s how we came to diaspora* AND ActivityPub! :)

      As far as intention goes, we can’t say. We don’t have a roadmap, or assigned tasks, or releases. Our issue trackers are populated with problems and developers who get excited by any one of them are invited to submit pull requests. To your question about s2s, I would invite you to check out https://github.com/magicstone-dev/acropolis/issues/92 and share, comment, click emojis, whatever you want to do to help prove it’s value and raise the probability that someone will work on it.

      tl;dr We do both, and we have no intentions either way but check out https://github.com/magicstone-dev/acropolis/issues/92

      • @southerntofu
        link
        22 years ago

        Thanks for the detailed answer! (the TLDR should be placed on top, though :P)

        Do you have a link to your ecosystem review? I’m curious about the notes you had about Hubzilla in particular, because it’s the only project i know of which is user-centric (you have a single account for all your activities, unlike AP ecosystem where peertube/mastodon accounts are separate) and interoperable (federates with AP/Diaspora/others).

        What would you think about a server-agnostic federation gateway? Couldn’t we have a gateway that speaks all protocols and merely “translates”, and that’s marked as trusted by your local node? The problem with such approach is usually it’s implemented using a specific server API (eg. matrix-bifrost bridge requires a matrix server to setup) but i don’t see a reason it has to be this way.

        • weexOPM
          link
          12 years ago

          I only considered about five projects, which was kind of silly considering there are dozens of projects out there and Hubzilla in particular I’ve heard about a lot. We could definitely use more different perspectives on how things can work in Magic Stone, it being so early, and with so much we don’t know. My perspective then was as a developer with a grand design for experimentation that has been replaced by the more incremental C4 process.

          I love the symmetry implied by a universal gateway that speaks so many protocols and understands how to map from one to another. In that vein a project called the-federation once worked on testing various protocols in one place and I bet a lot of that still works. Could be neat codebase to play with. That being said, it’s best for our community if we get to a problem statement. In this case, it might be something about disconnection or tribalism or lack of a global view, one fediverse kind of idea.

          It would be great to get your thoughts on this issue about pulling AP timelines together. Maybe once we solve that, or even in parallel, someone will pose another problem of collecting non-AP data and things will evolve from there.