Fedibird-FE Single Column View

Is there a way to force the single-column/mobile view in Fedibird FE like you can with Glitchsoc’s app settings in Mastodon-FE?

Thank you.

not right now, no - fedibird fe is highly experimental and is in a “just working” state at the moment

1 Like

Noob question here though: how do I access the fedibird fe? I mean, I have it installed, figured I should have a look at it, but have no idea on how to get to it. :rofl:

I was guessing it is using some kind of URL code, like masto-fe is using mydomain.com/web but so far everything I’ve tried has failed.

@Mathias You have to set what front-end to use. See Configuration Cheat Sheet - Akkoma Documentation

I had another FE on a subdomain in the past but cant remember how I did it lol. Having it on /web or /app or whatever would be handy, and can probably be done with nginx but I am too noob.

Ah, I see. Thanks. And even though I am using admin-fe for my config settings I should add the fedibird-fe things to the actual /etc/akkoma/config.exs file, that part isn’t possible to manage via admin-fe? I have an OTP install with database configuration, so kind of forgot that some settings probably still could live in the actual config file.

Does that also mean I will have to make a hard choice between fedibird-fe and akkoma-fe? I was hoping I could test fedibird in parallel, just like I can have masto-fe in parallel, as I really like, and normally use, my akkoma-fe, I just wanted to test fedibird for the sake of testing/learning.

You can do it via admin-fe as well (This is true for most settings btw). Admin-fe > Settings > Frontend > then look for section “Frontends” “Installed frontends management” > under “Primary” you can change “Name” and “Reference”.

Sadly yes, this way you have to make a hard choice between what front-end to use. As @snott mentioned, it should also be possible to have it on a subdomain, but that requires some magic on the reverse proxy (e.g. nginx) which I personally don’t have experience with (but if someone figures it out, a guide would be nice and maybe even something that could be added to the docs).

1 Like

Thanks!

As for the reverse nginx/proxy part I shall have a look at my old instance, which is still running though it is inactive. It has a Soapbox thing on a subdomain which I tested last year but had forgotten about, but I’m thinking that set-up might be able to run on things like these on my new instance too. I shall have a look when I get home (currently out-and-about and on my ipad, only).
If it has something re-usable I might be able to pull that in to a guide/instruction.

2 Likes

Memories of this thread popped up in my head today. Completely forgot it until now. Sorry.

Anyways, having a look at my old server, it really looks dead simple. It is literally a subdomain which has its own nginx config file and just points to the subfolder where I had Soapbox unzipped or downloaded from Git.

The one thing to look out for is that the certificates, in my case generated by certbot, also includes the subdomain and/or points to the location of the certificates for the main domain.

I shall copy in my config here, which I have removed my domain and subdomains from, but otherwise is like I found it on the server except that I have removed most of the commented out lines (I rarely delete in my config files, I mostly comment out).

It could be noted that it does not contain any of the nginx micro-caching stuff that I use on my current Akkoma server, this comes from my old server which didn’t have the latest tweaks I have on my current server, but I think it would serve as an indicator on what it should be.

server {
    server_name    [YOUR-SUB.DOMAIN.COM];

    listen         80;
    listen         [::]:80;

    # Uncomment this if you need to use the 'webroot' method with certbot. Make sure
    # that the directory exists and that it is accessible by the webserver. If you followed
    # the guide, you already ran 'mkdir -p /var/lib/letsencrypt' to create the folder.
    # You may need to load this file with the ssl server block commented out, run certbot
    # to get the certificate, and then uncomment it.
    #
    location ~ /\.well-known/acme-challenge {
        root /var/lib/letsencrypt/;
    }

    location / {
      return         301 https://$server_name$request_uri;
    }

}

# Enable SSL session caching for improved performance
#ssl_session_cache shared:ssl_session_cache:10m;

server {
    server_name [YOUR-SUB.DOMAIN.COM];

    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/[DOMAIN.COM]/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/[DOMAIN.COM]/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    #brotli on;
    #brotli_static on;
    #brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml;

    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/activity+json application/atom+xml;

    # the nginx default is 1m, not enough for large media uploads
    client_max_body_size 40m;

    root /opt/soapbox/static/;

    location / {
        try_files $uri /index.html;
    }

    location = /index.html {
        expires 30s;
    }

    # here goes long list of what we will use from real instance
    location ~ ^/(api|.well-known|nodeinfo|proxy|media|emoji|oauth|favicon.*) {

        proxy_pass       $scheme://127.0.0.1$request_uri;
#        proxy_redirect   $scheme://example.com$request_uri $scheme://soapbox.example.com$request_uri;
        proxy_set_header Host [DOMAIN.COM];
        proxy_set_header X-Real-IP $remote_addr;

        # doesn't work with some browsers
        # return 308 $scheme://d-x-b.com$request_uri;
    }

    access_log /var/log/nginx/access.soapbox.log;
    error_log /var/log/nginx/error.soapbox.log;

}


1 Like

Just for the sake of completion, I did try this out. I decided to install Mangane f-e in a separate folder and point a subdomain to it, using the config above. It worked, at least by-and-large. When doing a nginx -t it told me what needed changing here and there (duplication of ports with another site etc).

I now have Mangane on a separate sub-domain.

As a side-note, no matter which f-e I try out (and I do like trying them out) I tend to go back to the pleroma f-e.