This is not suited for the official outlet, so it will be posted here.My main activity in the last weeks has been thinking about order, structure, organization, expansion and start of infrastructure, and the many aspects of the system including how to maintain this the best way so that relevant parts of code can be shared with GuixSD.
Nothing is really “static” and fixed to what I wrote in the Email many weeks ago, the only fixed fact is that the goal is to make GNUnet universal usable.
At the moment I am writing a documentation handbook. I could simply develop on my own and wait for more people to ask where they could contribute, but infotropique maintenance and development will soon run on shared time.
Development is just a one person job at the moment, so I can’t really calculate any deadlines for first releases.
We are still discussing the source code repository location and workflow, so I’m sitting on some unreleased material, specifically the master repository.
Within the next months you should be able to:
- read the handbook, intended for contributors and those who want to become contributors (later it will be expanded, I just need to make a start for developers)
- point your guix pull to an URL which represents first individual pieces of this system
- and more
Today we are going to “package” Mastodon, as requested. Or at least document the theory before being put to practice (I actually lack the resources to run a public test node).
Requirement
We are going the “No Docker” route here first:
Missing packages in Guix: pidentd, node 4.x. We do have node 6.x though and 4.x (in theory) is only a matter of getting back to it.
Setup
And set up the database for the first time, this will create the tables and basic data:
RAILS_ENV=production bundle exec rails db:setup
Finally, pre-compile all CSS and JavaScript files:
RAILS_ENV=production bundle exec rails assets:precompile
Breaking up the language specific requirements
(as this is the Guix way, unbundling where possible)
gem ‘pkg-config’
gem ‘rails’, ‘~> 5.0.2’
gem ‘sass-rails’, ‘~> 5.0’
gem ‘uglifier’, ‘>= 1.3.0’
gem ‘jquery-rails’
gem ‘puma’
gem ‘hamlit-rails’
gem ‘pg’
gem ‘pghero’
gem ‘dotenv-rails’
gem ‘font-awesome-rails’
gem ‘best_in_place’, ‘~> 3.0.1’
gem ‘paperclip’, ‘~> 5.1’
gem ‘paperclip-av-transcoder’
gem ‘aws-sdk’, ‘>= 2.0’
gem ‘addressable’
gem ‘devise’
gem ‘devise-two-factor’
gem ‘doorkeeper’
gem ‘fast_blank’
gem ‘goldfinger’
gem ‘hiredis’
gem ‘htmlentities’
gem ‘http’
gem ‘http_accept_language’
gem ‘httplog’
gem ‘kaminari’
gem ‘link_header’
gem ‘nokogiri’
gem ‘oj’
gem ‘ostatus2’, ‘~> 1.1’
gem ‘ox’
gem ‘rabl’
gem ‘rack-attack’
gem ‘rack-cors’, require: ‘rack/cors’
gem ‘rack-timeout’
gem ‘rails-i18n’
gem ‘rails-settings-cached’
gem ‘redis’, ‘~>3.2’, require: [‘redis’, ‘redis/connection/hiredis’]
gem ‘rqrcode’
gem ‘ruby-oembed’, require: ‘oembed’
gem ‘sidekiq’
gem ‘sidekiq-unique-jobs’
gem ‘simple-navigation’
gem ‘simple_form’
gem ‘sprockets-rails’, :require => ‘sprockets/railtie’
gem ‘statsd-instrument’
gem ‘twitter-text’
gem ‘tzinfo-data’
gem ‘whatlanguage’
gem ‘react-rails’
gem ‘browserify-rails’
gem ‘autoprefixer-rails’
gem ‘rails_12factor’
gem ‘redis-rails’
gem ‘lograge’
Most of these gems and their dependencies are not available. So it’s mostly a matter of spending time to package gems.
For npm / nodejs the current recommendation seems to be: Give up, just embed a large binary blob for each direct dependency.
Conclusion
1. Packaging mastodon is not trivial.
2. Packaging the gems: I stopped setting deadlines in packaging, but my first impression is that it will take long.
3. The other effort will be to get the npm build system merged or get enough info so that we can rebase and use a branch based on jelle’s GSoC branch. Get more info on the state of it, etc.
Credits
Catonano
Obligatory Disclaimer: Read the upstream documentation and notices, especially the legal ones, about running tor relays.
Today in GuixSD on servers, we are going to run a tor-relay.
I assume you already went through the joy of installing a basic GuixSD somehow, somewhere and all you need is a system config which gives some insight into how to run this one-service specific server.
With the recent introduction of containers for system services in GuixSD, this adds some safety to running tor relays (not legal one though).
Please keep in mind that this is a theoretic construction, it will be put to practice once I can run a relay again for a short moment.
It also features no notice of adding your OpenSSH keys to the machine + setting a password.
Someone is working on making SSH keys an option in the system config, this post will be updated once it’s possible.
(use-modules (gnu)
(gnu system nss)
(srfi srfi-1)
(srfi srfi-26) ; cut
(guix store) ; %default-substitute-urls
(gnu services base)) ; %default-authorized-guix-keys
(use-service-modules desktop networking base ssh
version-control xorg avahi
dbus admin mcron)
(use-package-modules certs gnome vim
tor version-control admin
ntp suckless xdisorg
linux wget web
package-management tls ssh)
(define %tordate
#~(job '(next-hour '(4))
(string-append #$tlsdate "/bin/tlsdate -l -t -v -V")))
(operating-system
(host-name "noisemachine")
(timezone "UTC")
(locale "en_US.UTF-8")
;; Assuming /dev/sda is the target hard disk, and "my-root"
;; is the label of the target root file system.
(bootloader (grub-configuration (device "/dev/sda")))
(file-systems (cons (file-system
(device "/dev/sda2")
(title 'device)
(mount-point "/")
(type "ext4"))
%base-file-systems))
;; Assuming you have created a swap file named "swap.file" in the root of "/".
(swap-devices '("/swap.file"))
(users (cons (user-account
(name "user")
(comment "")
(group "users")
(supplementary-groups '("wheel"))
(home-directory "/home/user"))
%base-user-accounts))
(packages (cons* nss-certs ;for HTTPS access
emacs-no-x
nyx tor torsocks
%base-packages))
(services (cons* (service rottlog-service-type (rottlog-configuration))
(service mcron-service-type
(mcron-configuration
(jobs (list %tordate))))
(tor-service
(plain-file "torrc"
"#### This section is just for relays ####\n
## See https://www.torproject.org/docs/tor-doc-relay for details.\n
## Required: what port to advertise for incoming Tor connections.\n
ORPort 9001\n
## If you want to listen on a port other than the one advertised in\n
## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as\n
## follows. You'll need to do ipchains or other port forwarding\n
## yourself to make this work.\n
#ORPort 443 NoListen\n
#ORPort 127.0.0.1:9090 NoAdvertise\n
## The IP address or full DNS name for incoming connections to your\n
## relay. Leave commented out and Tor will guess.\n
#Address noname.example.com\n
## If you have multiple network interfaces, you can specify one for\n
## outgoing traffic to use.\n
## OutboundBindAddressExit will be used for all exit traffic, while\n
## OutboundBindAddressOR will be used for all other connections.\n
## If you do not wish to differentiate, use OutboundBindAddress to\n
## specify the same address for both in a single line.\n
#OutboundBindAddressExit 10.0.0.4\n
#OutboundBindAddressOR 10.0.0.5\n
## A handle for your relay, so people don't have to refer to it by key.\n
## Nicknames must be between 1 and 19 characters inclusive, and must\n
## contain only the characters [a-zA-Z0-9].\n
Nickname heckthecistem\n
## Define these to limit how much relayed traffic you will allow. Your\n
## own traffic is still unthrottled. Note that RelayBandwidthRate must\n
## be at least 75 kilobytes per second.\n
## Note that units for these config options are bytes (per second), not\n
## bits (per second), and that prefixes are binary prefixes, i.e. 2^10,\n
## 2^20, etc.\n
#RelayBandwidthRate 100 KBytes # Throttle traffic to 100KB/s (800Kbps)\n
#RelayBandwidthBurst 200 KBytes # But allow bursts up to 200KB (1600Kb)\n
## Use these to restrict the maximum traffic per day, week, or month.\n
## Note that this threshold applies separately to sent and received bytes,\n
## not to their sum: setting "40 GB" may allow up to 80 GB total before\n
## hibernating.\n
## Set a maximum of 40 gigabytes each way per period.\n
#AccountingMax 40 GBytes\n
## Each period starts daily at midnight (AccountingMax is per day)\n
#AccountingStart day 00:00\n
## Each period starts on the 3rd of the month at 15:00 (AccountingMax\n
## is per month)\n
#AccountingStart month 3 15:00\n
## Administrative contact information for this relay or bridge. This line\n
## can be used to contact you if your relay or bridge is misconfigured or\n
## something else goes wrong. Note that we archive and publish all\n
## descriptors containing these lines and that Google indexes them, so\n
## spammers might also collect them. You may want to obscure the fact that\n
## it's an email address and/or generate a new address for this purpose.\n
ContactInfo Random Person \n
## You might also include your PGP or GPG fingerprint if you have one:\n
#ContactInfo 0xFFFFFFFF Random Person \n
## Uncomment this to mirror directory information for others. Please do\n
## if you have enough bandwidth.\n
DirPort 9030 # what port to advertise for directory connections\n
## If you want to listen on a port other than the one advertised in\n
## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as\n
## follows. below too. You'll need to do ipchains or other port\n
## forwarding yourself to make this work.\n
#DirPort 80 NoListen\n
#DirPort 127.0.0.1:9091 NoAdvertise\n
## Uncomment to return an arbitrary blob of html on your DirPort. Now you\n
## can explain what Tor is if anybody wonders why your IP address is\n
## contacting them. See contrib/tor-exit-notice.html in Tor's source\n
## distribution for a sample.\n
DirPortFrontPage /var/www/tor-exit-notice.html\n
## Uncomment this if you run more than one Tor relay, and add the identity\n
## key fingerprint of each Tor relay you control, even if they're on\n
## different networks. You declare it here so Tor clients can avoid\n
## using more than one of your relays in a single circuit. See\n
## https://www.torproject.org/docs/faq#MultipleRelays\n
## However, you should never include a bridge's fingerprint here, as it would\n
## break its concealability and potentially reveal its IP/TCP address.\n
#MyFamily $keyid,$keyid,...\n
## A comma-separated list of exit policies. They're considered first\n
## to last, and the first match wins.\n
## If you want to allow the same ports on IPv4 and IPv6, write your rules\n
## using accept/reject *. If you want to allow different ports on IPv4 and\n
## IPv6, write your IPv6 rules using accept6/reject6 *6, and your IPv4 rules\n
## using accept/reject *4.\n
## If you want to _replace_ the default exit policy, end this with either a\n
## reject *:* or an accept *:*. Otherwise, you're _augmenting_ (prepending to)\n
## the default exit policy. Leave commented to just use the default, which is\n
## described in the man page or at\n
## https://www.torproject.org/documentation.html\n
## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses\n
## for issues you might encounter if you use the default exit policy.\n
## If certain IPs and ports are blocked externally, e.g. by your firewall,\n
## you should update your exit policy to reflect this -- otherwise Tor\n
## users will be told that those destinations are down.\n
## For security, by default Tor rejects connections to private (local)\n
## networks, including to the configured primary public IPv4 and IPv6 addresses,\n
## and any public IPv4 and IPv6 addresses on any interface on the relay.\n
## See the man page entry for ExitPolicyRejectPrivate if you want to allow\n
## "exit enclaving".\n
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports on IPv4 and IPv6 but no more\n
#ExitPolicy accept *:119 # accept nntp ports on IPv4 and IPv6 as well as default exit policy\n
#ExitPolicy accept *4:119 # accept nntp ports on IPv4 only as well as default exit policy\n
#ExitPolicy accept6 *6:119 # accept nntp ports on IPv6 only as well as default exit policy\n
ExitPolicy reject *:* # no exits allowed\n"))
(avahi-service)
(wicd-service)
(upower-service)
(colord-service)
(geoclue-service)
(polkit-service)
(elogind-service)
(dbus-service)
%base-services))
Multiple people are documenting their efforts and fights with clouds, kvm, xen, and other virtual systems to run GuixSD on.
Most of these platforms don’t differ from each other very much, so this serves also as a test to improve GuixSD to make the individual tweaks unnecessary.
However in the meantime, a centralized place to gather all the documentation is important. I’ll write down my own attempts, and I will collect emails from the list about initial server setups. For now I will collect them here on this web log.
Currently I’m working on:
Limitations are:
- time … I’m bootstraping/starting pragmatique for the next months
- money … some platforms, companies, and other entities are located in regions where running servers can’t be done for the (usual) unfair price of $5/month. Speaking of money: Rejoice hosters of virtual servers, we will throw cash at you for testing a system!
Eventually this should end up in a series of finalized posts which are easy to read (easy, non-technical language) and extend or work together with the pretty good documentation of Guix. You wonder how to install GuixSD at your hoster/cloudcastle XY? No problem, read this. Ideally it will be like my current experience with GuixSD where the basic setup is done in less than 30 minutes (depending on the status of hydra).
Eventually these guides will be moved over to some subdomain at pragmatique.xyz
We are the Guix. Your biological and technological distinctiveness will
be added to our own. Resistance is futile.
This post briefly describes how to install GuixSD on Debian 8, the Borg way.
Please be aware that this post is a draft as the system I am using is still building. Currently this means what exactly you need to remove from /etc/ must be documented otherwise you boot into a non-functional system with mounting issues.
If you lack the time to work on a package and you have no specific deadline for it,
you can message me with your requests.
Please mark the email with accordingly so that I can filter them later on, I suggest starting the subject line with “[packaging request]”.
If you do this, please support me on either flattr or patreon (more platforms will eventually be added).
Currently I work on an 1:1 port of torbrowser for Guix (longterm fun project), and completion of the mailman3 packages. Other work in progress packages can be found here.
This is a response to mashable.com – mastodon-wont-survive. It’s an early public draft, later versions will go more into depth of explaining certain concepts of networks which I do imply knowing here.
As a personal information, I’m neither involved with mastodon development nor do I speak for the project. In fact I’m advocating methods to make the majority of server based networks obsolete in the long run.
Shel Raphen, one of the people who are actively contributing to Mastodon’s codebase wrote an essay here. It was so obvious that I failed to include in this text the fixation of “killing networks” and “financial support” in the press.
This news post reads like a mixture of misunderstanding of federation and just mocking.
Let’s look at everything Mastodon gets wrong.
1) Terrible name
Mastodon implies large, slow, frozen, and dead for thousands of years. The logo is cute, but the service right now stinks almost as badly as a thawing woolly mammoth.
What’s in a name anyway? Softwareprojects and companies don’t have a record for original names (look at twitter, facebook, diaspora), and when they do have original names they tend to be way over the top with too much rocket gear added to the name finding process.
2) There is no single Mastodon
In trying to satisfy a spike of new users, Mastodon broke the cardinal rule of social media: it separated them into silos and made it hard if not impossible for them to all socialize. This unfortunate design makes Mastodon feel more like a bunch of chat rooms rather than a cohesive, growing social network. The Federated Timeline helps, but it’s not the default view.
And I get that having a decentralized social media platform, Mastodon creator Eugen Rochko’s big idea, helps create safe zones from groups and topics, but it’s really a terrible approach that will lead to a stagnant growth and way more opinion bubbles, which is the last thing we need.
(Growth for the growth deity.)
But my dear author, it is federation by design. Let me first introduce this with a picture:
Socialmedia networks do not have to re-use models we currently know as succesful as they get rich by making money of your metadata. Twitter, Facebook, and GooglePlus all are corporate networks with a centralized structure. Mastodon is not the first federated network. Other kinds of networks exists and are in the making (distributed ones). The overall concept of the internet and its earliest usecases was a federation. Email as we know it today is federation. Fidonet, started in 1984, still has 3,652 active nodes and it is federated. Diaspora, even if there might be no longer that much coverage in the press, is federated, has 328 active nodes and around 17.000 users.
To present a more precise usecase of federation you can experience, here’s a diagram by @vhf I am allowed to use (click to see the full size):
3) Toots
In trying to be the anti-twitter, Mastodon’s Rochko chose the dumbest and most ridiculous post name possible: Toots. This too-cute take-off on Tweets literally hurts me every time I say and do it on Mastodon.
See above, regarding names. It’s a personal opinion, I think toots are as random as tweets.
4) Handles are meaningless
User handles do show up in Toots (blech!) but not in the URLs for users’ Mastodon homepages. Giving users numbers (mine is 995) instead of identifiable website addresses makes Mastodon feel amateurish.
Actually they do: @vhf has the handle vhf and the public URL https:// techn.ical.ist/@vhf. What precisely is amateur when it comes to how you format URLs for profiles? In the end you do not interact with the URLs, you interact with the people. I did not see the issue the author of the post raised, so I suppose this is just mocking.
5) Where is everyone?
If you can’t find people by name, then how can you follow them on Mastodon? Someone in one local Mastodon timeline may not appear in another (Sorry, Mr. Shatner). To see everyone (at least I think you see everyone), you have to troll the Federated timeline, open a Toot (blech!) and add them there. Twitter and other social networks already have this stuff figured out. Why is Mastodon better? It’s not!
It’s not as obvious as it is, and should be explained better. You know that for software project bugs can be reported. This is a known (?) documentation bug, for a current explanation take a look at the 2nd image here.
6) Apps feel like a science project
I started using Mastodon in Safari. It was not a good experience. At least there’s an app…or apps.
There is no one app called Mastodon. Instead, you can find a Github list of apps for the open-source project. Apps like the iOS-based Amaroq let you log into any of the many Mastodon “instances” by typing in the name. Nope, there’s no list of instances because I don’t think anyone knows just how many Mastodon instances are out there.
One app per child!
Why is having no centralization of client applications considered bad? It’s about the freedom to create an application and choosing one of many compatible clients, and not being forced to use THE mastodon app.
There is a list of instances and it is being advertised on most instances sign up pages:
https://mastodon.social/about displays a link to this https://instances.mastodon.xyz/ public listing of instances which chose to be displayed.
The Internet is a big place — universe-big — so there’s room for another social media platform, but the Internet can also feel like a very small place, one that targets the weak and consumes them quickly.
Mastodon cannot live on hype alone.
Mastodon has potential. It can be easy to use and there are clearly a lot of people trying it right now. But its weaknesses are glaring. It’s more project than product. Unless someone buys the code off Rochko today and consolidates this mess ASAP, it can’t survive.
This implies that succees can only be achieved if you are throwing money at a project. You have facebook. Companies and other investors have decided to throw money at it, yet it is a threat to democratic systems and human rights. Still people use it. You an throw money at it, but what makes a good project is passion and community interaction. I don’t see a future where facebook opens up contributions to its core code by volunteers with no hidden intentions.
And, no, Mastodon cannot live on hype alone.
I fully agree. But does it have to grow that much? Federated social networks do not scale to world population sizes. Forms of distributed networks can achieve this. Federation still features the same trust issues (points of authority) as centralized networks. The advantage of federation is that you can be transparent about what you publicly state you do, don’t do and if people don’t agree they can move on. I would not say we are at the point where anyone can run a server. Among SysOps knowledge this requires skills and time to debug software, failures etc which normally happen in operation of any software on any network. A small step in the right direction would be a Guix package for Mastodon and system services for it on GuixSD, so that it can be as easy as putting a couple of configuration lines into your local system configuration, run guix system reconfigure, reboot and have a a functional Mastodon node!
Remember Peach? It, too, was a fun social network that let you keep track of friends and share funny images. It was a crappy version of Snapchat without all the sexting.
Peach enjoyed a solid two weeks of being the hottest thing on the social media planet. Then, as I predicted, it fizzled. The last time we talked about Peaches and technology was when Apple changed the peach emoji so it no longer looked like a butt (and then changed it back). No one even mentioned the now mostly forgotten Peach social network.
Late last night on Twitter, we quickly reached the same conclusion: Mastodon is more Peach than Twitter, Less Snapchat than Path.
I was already ready to move on. So was Shatner.
I suspect thousands of other Tooters (blech!) will soon do the same and Mastodon will lay down beside all other other fossilized social media platforms and fade from existence.
