I figured I could simply upload them on our webserver, so here you go:
- Sound of the cleaned keyboard: https://quantentoast.de/ibm-model-m-cleaned.mp4
- Sound with tapemod applied (no very noticeable on the video): https://quantentoast.de/ibm-model-m-tapemod.mp4
Thank you
I can't imagine the sound of a room with like 20 pupils, each hammering on such a keyboard.
I'll do that! Question is where to post it. Lemmy doesn't support videos.
When 4 IBM Model M keyboards showed up during a cleanup at work (university) and I was asked if I wanted one, I of course said yes!
It's an IBM model M 1394540 from 1992 with the PS2 connector and the detachable cable. The keyboard and cable are in very good condition, even the manufacturing sticker on the back looks pretty good! All keycaps present, all keys work. It just needed "some" cleaning which ended in a 3h long process haha.
It will definitely be my daily driver for the next few weeks. I haven't decided yet if I will use it long term. I'm actually very happy with my modded Keychron Q6. Maybe I'll try some lube on the stabilizers and perhaps a little tape mod.
The best part was that I got to take a second Model M with me, which I will give to a good friend. This one is also in great condition.
It was an incredible day!
GDPR Compliance Check
For those who haven't heard of it before, Gumb is > A platform for managing meetings, gatherings, and events for communities of any size. - gump.app/en
I have investigated this app because it is used by a club where I am occasionally active.
Landing Page / Homepage
Fonts: The landing page is using google fonts, so those fonts are loaded (8 requests) from fonts.gstatic.com
when opening the website.
The first issue here is that google fonts are not listed in the privacy policy at all.
Second, by a German court ruling google fonts are not compliant with the GDPR:
> The use of external font services cannot be based on Art. 6 § 1 p.1 f GDPR, as the use of the fonts is also possible without having to establish a connection from visitors to external servers. - LG München Az. 3 O 17493/20
Images: Furthermore the website is loading images from firebasestorage.googleapis.com
(105 requests). Following the argumentation of the previously mentioned court ruling, using firebase for images could also be considered non-compliant because images could easily be served without having to establish a connection from visitors to external servers.
Youtube Embed: The website includes a youtube iframe (13 requests to www.youtube.com
) with an introduction video. While youtube themself offer an iframe option called "Enable privacy-enhanced mode", the Gumb homepage embeds the »normal« iframe that places tracking cookies which again violates the GDPR.
The iframe furthermore sends
- 6 requests to
play.google.com/log
, - 4 requests to
https://googleads.g.doubleclick.net
- 1 request to
https://static.doubleclick.net
- 4 request to
https://jnn-pa.googleapis.com
Tracking: The website uses, as stated in their privacy policy, Google Analytics (GA) which results in a request to https://region1.analytics.google.com/g/collect...
and https://www.googletagmanager.com
. However, writing "we use GA" in the privacy policy is not sufficient. GA requires consent from the website visitor.
There are a few more unnecessary requests, but I think the point is clear.
All of that is happening without any consent from the visitor!
Mobile App
Gumb offers mobile Apps for Android and iOS, of which I only checked the Android version. While I can't say for sure that the app violates the GDPR because it immediately asks for credentials, the Exodus Privacy Report (of the latest version 1.0.84) still looks rather bad:
- Amazon Analytics
- Amazon Mobile Analytics
- Google Analytics
- Google CrashLytics
- Google Firebase Analytics
- Google Tag Manager
Web App
Next to mobile apps, Gumb offers a web app too. Well, what can I say - there are requests to
https://fonts.googleapis.com
https://www.googletagmanager.com
https://region1.analytics.google.com/g/collect...
https://www.google.de/ads/...
https://stats.g.doubleclick.net/g/collect...
https://ipgeolocation.io/
even without being logged in or any given consent.
Conclusion
For a tool from Switzerland with paid subscription plans and the purpose of managing events/meetings etc. it uses a lot of google (tracking) services... Very sad to see as the app looks otherwise really modern and useful. Do today's developers know that applications like Gumb can be implemented without selling their users' soul to google?
Nice, thanks for sharing! Mine looks like this atm:
- HS: Mainly Docker containers and VMs
- VPS: Wireguard to relay traffic (NAT) to the HS (SSL termination on HS)
- UPS in case of power outage
- Pi4 for backups within the local network. It also has a disk station for regular air gapped backup.
- Pi3 for off site backup
- Fire extinguisher nearby in case of emergency ^^
Die spannende Frage ist: Bekommt er das Bier erstattet?
Been there, done that. Volatility is something you learn pretty early, yes. ^^
First: Good for you, enjoy the journey! Second: Just as others already pointed out, Mastodon is not really a beginner project. You want to understand what you are doing, not just make everything work no matter what. Some reasons why I'd not start with Mastodon:
- Complex deployment stack (for beginners)
- Needs regular maintenance
- Security considerations (if you haven't managed/hardened a server before)
- Long term project
So instead: Have a look at awesome-selfhosted for ideas. A personal dashboard, photo gallery or a PiHole/AdGuard is a good start.
About Docker; it's a bit more than just dependency separation. It's a kind of virtualization, but without each container running it's own kernel. Advantage is: Docker images run (with some configuration) relatively lightweight out of the box. So there's no need to install the applications natively. While I'm a great fan of Docker, you'd probably learn more installing things natively in the beginning. Or maybe do both, it's up to you. However, if you decide to use Docker, be sure to understand what's going on under the hood. That's where the fun begins. Everyone can pull and start images, but not everyone knows how to customize or build them themselves.
No matter what you decide to do, have fun. And if you've any questions, there's plenty of documentation online or just ask. The selfhosting community is very welcoming towards new members ;)
Small Update: When uploading images from the tor mirror, they are stored in the DB with the onion address. One workaround I'm currently applying is running a script periodically that updates image links. It looks like this:
UPDATE post SET url = REPLACE(url, 'http://your-hidden-address.onion', 'https://your-clear-domain.tld')
And btw all this is for version 0.18.3 (to avoid confusion in the future)
Don't worry, nothing is easy in the beginning and yes, some docs are not up to date because Lemmy has such a steep development curve and therefore frequent changes.
[...] i think i might try to do it again tomorrow after the frustration of failure of today is gone and i have some more motivation.
Do have any other self hosting experience? Maybe a software that is a bit more easy to handle would be a good starter. With that, you can experiment and learn a bit, before starting a (long term) project that requires proxy, database, frontend, backend and configs to make them work together. Not to speak from the maintenance.
Is it okay if i just ask my questions to you directly in this thread?
Sure thing. I can recommend the Lemmy admin matrix chat as well (if you're a matrix user).
Do you mean DynDNS with the automatic updates?
What I mean is: best case is your provider offers an api which allows you to update the DNS records by running a simple script. What I would not recommend is using something like mylemmy.dyndns.org
(or similar services) for a Lemmy instance.
Since your question is quite basic and general, I'll try to answer equally.
-
Hardware: For a single user instance a Pi 3B+ is sufficient. Still, Lemmy can take up some storage space over time because of the images. So make sure you don't take the smallest SD card you have lying around. I assume you know how install an OS and get basic things running.
-
Get a domain; there are many providers out there. Consider using a TLD of your country (e.g.
.de
,.fr
). Domains are usually relatively cheap. You're most likely running your Pi at home, so check if you have a static IP address or if you have a dynamic one. First one? Great, go ahead. Second one: Check if your domain provider offers an API to automatically update the DNS record; example provider api. -
Have a look at the Lemmy administration docs. Depending on your experience, it is relatively easy to setup. Make sure you understand what you're doing, i.e. first get to know Docker for example, then follow the commands. If you don't understand something, just ask or search online. Lemmy is not very complex to operate, so for every part of the deployment you should be able to find information online.
-
Set up port forwarding in your router for ports 80 (HTTP) and 443 (HTTPS). You can find information for your specific router online, but for some routers this cannot be done.
-
Get a SSL certificate for your domain. You can get one for free with Let's Encrypt.
-
Once you have your instance up and running, I would recommend setting it to "private" first. This way you can play around with your instance or reinstall if something goes wrong without having to worry about federation. Once you've federated (communicated with other instances, e.g. by subscribing to communities of other instances), you really shouldn't reinstall!
I hope this helps you with the first steps. Decide for yourself if you want to deal with maintenance and administration "long term". It's perfectly fine to use other instances and not host Lemmy yourself if you don't feel up to it. After all, there is also a security aspect to consider. If you do: have fun with self-hosting!
Current State
One controversial topic within the admin community is Tor. Many malicious actors that want to harm an instance hide behind the tor network, which is why many instances block traffic originating from Tor. The most common approach is to block requests from exit nodes, a list of which can be found here. Tor blocking is a valid principle that every instance operator must decide for themself. I do not condemn anyone for doing so.
Motivation for Tor
However, Tor is also a tool to use the Internet in an anonymous way, bypassing censorship or big firewalls. This means that there is a legitimate use case for the combination of Tor and Lemmy. There is even an official Lemmy documentation on how to run a Lemmy instance as a hidden service.
The Issue
There is, however, one significant issue at this point: Picture requests are leaking.
On the normal web, all requests go to https://lemmy.tld/...
, including image requests that look like https://lemmy.tld/pictures/image/...
. In Tor, you access http://xyz.onion/
, but the image requests still use https://lemmy.tld/pictures/image/...
. From a Tor perspective, this is not intended and defeats the purpose of a hidden service. Yes, you are still anonymous, but the traffic through the exit nodes is slow (traffic within the tor network is »faster«) and not even necessary in this case.
The reason for this problem is that the image links are stored in full length in the database. For example, an image has the id 1a2b3c4d
and is stored in the DB as https://lemmy.tld/pictrs/imate/1a2b3c4d
. This leads to requests for images (of the same website you visit via tor) take the long route to the clear web.
Proposed Fix
I have delved into the lemm-ui source code and developed a fix for this problem. Unfortunately, this is not a universal solution and only works for our QuantemToast (de/en) instance. However, it is easy to customize it for your instance. Just change the domain name in src/shared/utils/app/substitute-image-url.ts
and build your own Docker image. It works by replacing the instance domain with the onion domain for image URLs (and the favicon).
Perhaps someone is interested in developing a general solution, but until then, those of you who want a Tor instance or just a Tor mirror (our use case) might like to take a look at my solution.
Edit: Use at your own risk.
Please Note
Be aware, that content from other instances might not be visiable due to mentioned Tor blocking. Furthermore federation is currently not supported for Tor instances. Federation traffic between instances is handled on the clear web.
If you just want a Tor mirror, you might want to consider using a single onion service for better performance.
Edit: Changed fix link from commit to branch. Had to change something because of icon leak
That's an interesting question. At the time being, I think the only way is to do regular backups and store them at a friends for example. That way an instance can be restored after the server has been taken.
Really the only way is to not save anything, or perhaps some sort of blockchain for all the comments and posts?
Blockchain is an interesting thought - or maybe something similar to Matrix. All instances have their own copy of a post and sync with each other. That way it doesn't matter if one instance disappears. Though, that would probably not comply with the Fediverse idea? Interesting thought experiment non the less!
I get your point. Then, why not start your own instance with rules that you approve? I know, easier said than done, but that's the nice thing about the Fediverse. Next to the general purpose instances, there are many "themed" ones with focus groups such as musicians, journalists and so on.
You lying to yourself or have unfounded expectations.
Nobody mentioned any expectations hm...
Everything on Mastodon is in plain text, there is no encryption, and servers get mirrored.
That's 100% correct, and I think it's important to explain that to non-techy users.
It’s only the login info that stays with the instance [...]
Technically yes, but I'd cut the "only" because login info includes the users email. So in case of a raid or data breach, I'd like to know about it.
The entire point of why Mastodon was ever started was censor evertbody that has the wrong opinion. Twitter wouldn’t delete people because of what they believe, so Mastodon was developed to ban IP address so only approved speech could exist on the internet as far as they are concerned and can avoid ackniwledging the real world. A high number of people on there, especially the admins, live in cult
I don't know what places on Mastodon you've visited, but that's not the point of Mastodon or the Fediverse in general at all. But we don't have to start a discussion about that since you seem to already have made up your mind about it.
As far as I know they seize everything if there's a warrant. No matter whether it's relevant for said warrant.
Edit: Sorry, misunderstood your comment; Don't know what the reason for the warrant was.
Bei einer Hausdurchsuchung hat das FBI als "Beifang" auch einen Mastodon-Server erbeutet, auf dem ein Backup gerade in einem unverschlüsselten Zustand war.
We’re in an exciting time for users who want to take back control from major platforms like Twitter and Facebook. However, this new environment comes with challenges and risks for user privacy, so we need to get it right and make sure networks like the Fediverse and Bluesky are mindful of past...
cross-posted from: https://postit.quantentoast.de/post/18942
> I thought this might be of interest to other users as well as admins.
We’re in an exciting time for users who want to take back control from major platforms like Twitter and Facebook. However, this new environment comes with challenges and risks for user privacy, so we need to get it right and make sure networks like the Fediverse and Bluesky are mindful of past...
I thought this might be of interest to other users as well as admins.
Hab dein Post eben erst entdeckt. Für den Fall das es hier noch jemanden interessiert: Ich persönlich kann Ionos empfehlen. Domain und Mail haben über Jahre nie Probleme gemacht. Auch vServer haben mir die beste Erfahrung geboten. Hatte viele Anbieter über die Jahre ausprobiert (darunter Contabo, Strato, ...), aber keiner kam an die Performance und Uptime von Ionos ran.