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. 
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