home.social

#epicyon — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #epicyon, aggregated by home.social.

fetched live
  1. @tofeo apologies on my delayed response. I tried to look for #epicyon public instance examples but wasn't able to find any.

    But then upon taking a deeper look it looks like this is by design as Epicyon discourages public instances, please see: codeberg.org/bashrc/epicyon/sr

  2. Epicyon ("more than a dog")
    is a large, extinct, canid genus of the subfamily
    Borophaginae ("bone-crushing dogs"),
    native to North America.

    Epicyon existed for about 7 million years
    from the early Clarendonian age of the Late Miocene to the late Hemphillian age of the Early Pliocene.

    E. haydeni is the largest known canid of all time,
    with the type species reaching
    2.4 m (7.9 ft) in length,
    90 cm (35 in) in shoulder height
    and approximately 100–125 kg (220–276 lb) in body mass.

    #Epicyon #Canid #Borophaginae
    en.wikipedia.org/wiki/Epicyon

  3. @duckerer Нужно быть более-менее на ты с #Linux-терминалом.

    Нужен #сервер (домашний или на хостинге: виртуальный или железный). Если #хостинг (что обычно разумнее, чем домашний сервер) и именно #Mastodon, то будет не очень дёшево; AFAIK, #Мастодон требует не меньше 4 гигабайт оперативной памяти.

    Помимо Мастодона, есть и другие варианты (обязательна поддержка #ActivityPub): #Pleroma, #Misskey и другие; а если без свободной регистрации, то #snac2 (только для себя) и #Epicyon (для себя и друзей).

  4. Despite this (a limitation that should be relatively easy to fix/change; there are probably more), I'm now actually considering spinning up an experimental personal #Epicyon instance. I think this is the first piece of #Fediverse software that has made me think it might be time to set up my own plaything. It probably won't be “right now” though, but only because I have way too much stuff in my hands at the moment and the last thing I need is experimenting with a new server software.

    3/

  5. So I'm checking out #Epicyon libreserver.org/epicyon/ (which I discovered thanks to @atomicpoet), which might be just the kind of AP server I'm looking for. I delved into the code to check how it stores the data and it seems it's going with the “static files” approach over the DB used by basically anything else, and this is pretty much what I was hoping for (I'd be OK with something lightweight like sqlite to cache the metadata for speed, this one seems to use text for that too?)

    1/

  6. CW: Low-tech personal media NAS / cloud ⅓

    #SelfHosted #Media #Backup

    I have been trying to gravitate to a simple system for keeping organized "tagged" collections of photos/videos/documents backed up and lazily synchronized across multiple smartphones/laptops and a NAS of sorts on the home network. Off-the-shelf options (#GitAnnex, #Perkeep, #Epicyon, #PhotoChiotte, #Nextcloud/ #Owncloud, #Synology) all seem to only address parts of this common use-case.

  7. @leonieke @meneer why not do a trial run of #Hubzilla or its successor #Streams ? Available in Yunohost, I believe. Nowhere as complicated to admin, and compatible with many protocols, not just ActivityPub.

    Or #Epicyon, which is said to be even less complicated.

  8. @sass my usual not-based-on-experience thought is #Epicyon (no database server to run).

  9. @sass Epicyon is a Fediverse server with a static webpage interface, no database in the backend, and additional non-micro-blogging features.
    #Epicyon epicyon.net

  10. Added support for federated blocks in #Epicyon. With admin or moderator role you can specify blocklist API endpoints containing a list of blocked domains or handles, and those will then be used in addition to the local instance level blocks. So if you had an instance running at each location of an organisation and wanted them to all follow the same blocklist without manual intervention then you could do that.

    The blocklist endpoint only needs to be a json list of strings accessible via HTTP GET, so very simple to set up.

    ☇ Of course, this is a hazardous feature and so you need to have ultimate trust in whoever is maintaining the blocklist. If you fuck up then a malevolent blocklist maintainer could trash your instance, making it unusable.

  11. Im Augenblick "eskaliere" ich voll im #fediverse ...

    Eigene Firefish-Instanz aus Mangel an Hoffnung entfernt. Neben
    #misskey auch #sharkey installiert. Alles läuft da auch nicht perfekt... aber sehr gut.

    Aber eine Fallback-Instanz hätte ich dann doch schon gerne. Was tun?

    Und nun die "Eskalation":

    2 x mit eigener
    #mastodon Instanz experimentiert. Neee! Bei beiden Installationsversuchen (jeweils auf frischer, "jungfräulicher" Subdomain) hat das meinen Plattenspeicher "aufgefressen". Plötzlich waren statt um die 30% von 150G knapp 80% verbraucht. Und das, obwohl ich im Bereich Caching etc. so ziemlich alles auf "speichersparend" konfiguriert habe.

    Also gestern einfach mal
    #mastodon-glitch ausprobiert, den Mastodon-Fork. Und das hat den Plattenplatz nicht aufgefressen. Super! Nur... die Prozessorlast ging bei vier Kernen gegen 100%! Sidekiq-Prozesse ohne Ende... mit ordentlicher Prozessorlast.

    Hmmm... was ist denn mit den einfachen, unbekannten und frischen Projekten?

    #GoToSocial z.B. Probiert... echt zu "alpha" und wirklich noch zu unfertig.

    Na dann mal was ganz "exotisches":
    #epicyon
    Noch nie gehört? Kein Wunder.
    Ist aber was besonderes. Kommt ohne Javascript aus, weshalb es sogar in Konsolenbrowsern nutzbar ist. Basis ist Python. Eigentlich keine schlechten Voraussetzungen. Lief auch recht gut. Aber auch noch sehr, sehr "alpha". Einige Sachen gingen einfach nicht. Hat aber Potential. Ich werde es beobachten.

    Heute bin ich dann bei
    #pleroma gelandet. Bis jetzt bläht es sich weder im Plattenspeicher aus... und die Systemlast ist auch absolut moderat.
    Mal schauen, ob das mein "Fallback-Dienst" bleibt. Ansonsten habe ich ja immer noch meine gute, alte Hubzilla-Instanz, die sauber und zuverlässig läuft.

  12. Codename for the next #Epicyon version is "Bounding Bassett"

  13. Prepping for the next release version of #Epicyon. I think it's in pretty good shape, and there have only been incremental changes over the last year.

    This type of instance will not be to everyone's taste. It deliberately doesn't scale, has no database and supports only a few user accounts. There is no javascript, and the coding style is intended to be boring, with no trendy or advanced computer science concepts. The code is not clean, and uncle Bob would not approve. But it is maintsinable. The design decisions are for resilience, and continuing to support text mode browsers is quite useful.

  14. @smallcircles
    To be fair, we get a sense that many instances are operated by those who are invested in highly questionable endeavours, which make them function similarly to a large corporation.

    One of the goals of Fediverse proponents like us is to make setting up secure instances fairly easy, and not too burdensome. We think #Mastodon isn't able to provide such, but with #BloatFE and no javascript, maybe it can.

    We wonder how #GNUSocial and I2P-friendly #Epicyon (eg. #LibreServer) might help.