You can create accounts for development using whatever hostname you want to, as long as it resolves to your local machine. I, for example, have set up my local DNS to resolv any hostname with the
.local TLD to resolv to localhost, which means I can run pods at
podb.local for local federation testing, for example.
While you technically could interact with actual pods, it doesn’t make much sense. If you’d deliver a post, we’d try to fetch the profile, and well, fetching from 127.0.0.1 does not end well for production pods. So you’d end up nowhere. Even if delivery would work, it still would be a one-way-only connection, as you’d never get something back.
If you want to do local federation testing, it’s best to either start two diaspora instances on different pods, or to start two instances of your VM and have them talk to each other. In the first case, make sure that the
url key in the
diaspora.yml includes the port as well, so that the diaspora handle (the
username@host thing) includes the pod as well. In the second case, you’d need some kind of internal network for the two VMs, so that they are connected to each other, and then set the
url to the IP that is reachable from the other VM.
Note that changing the
url in the config requires you to drop the db and create it again (
bin/rake db:drop db:create db:migrate), because the hostname parts of diaspora handles are hardcoded in the database.
That all being said, having multiple diaspora nodes talking to each other is usually not required for diaspora* development, unless you actually want to work on something related to the federation layer. So a single local pod using
127.0.0.1 as hostname should be totally fine for most development tasks, without the need of communicating with other pods.
Since this is an important question, I changed the title to have this post related to a local federation testing setup, to make searching easier for future developers. If you have other questions, feel free to simply open a new thread.