just tell them “it’s been a long time”

except: pass

thanks!

here is a side-by-side comparison of the neural network upscaling slop (left) versus a conventional zoom in on the original (right):

and then of course there is the text:

😦

nice work!

deleted by creator

The server isn’t exposed to the internet. It’s a local IMAP server.

if it is processing emails that originate from the internet, it is exposed to the internet

security updates are for cowards, amirite? 😂

seriously though, Debian 7 stopped receiving security updates a couple of years prior to the last time you rebooted, and there have been a lot of exploitable vulnerabilities fixed between then and now. do your family a favor and replace that mailserver!

From the 2006 modification times, i wonder: did you actually start off with a 3.1 (sarge) install and upgrade it to 7 (wheezy) and then stopped upgrading at some point? if so, personally i would be tempted to try continuing to upgrade it all the way to bookworm, just to marvel at debian stable’s stability… but only after moving its services to a fresh system :)

i’m not aware of anybody who allows public signups and is interoperating with bsky.app yet (besides Bridgy Fed which will create an ATP identity for your ActivityPub identity), but I’m pretty sure it is possible because I follow people there who appear to be doing it for themselves.

see also my reply to you in another thread.

Very interesting, thanks! Is it possible for people to register on that relay?

(if I understand correctly) you don’t register on a relay, you register on a PDS (which you can easily self-host on a small computer at home). But, to register with a PDS, you need a DID, and to interoperate with the rest of bluesky it needs to be using one of their two currently-supported DID methods: either did:web or did:plc. The former is a thing which you can create using a domain you control, which gives you an identity that you lose control of when you lose control of that domain. The latter is the actually-centralized “placeholder” DID method implemented by an append-only log operated by BlueSky PBC, which is what most people are actually using. I’m not sure if/how you can create a did:plc without first creating an account on a bsky.app PDS, but you can migrate it to your own PDS after creating one there. or, you can use did:web and rely on your domain name registration instead of their centralized log.

Further reading:

• How to self-host all of Bluesky except the AppView (for now) (from November last year)
• minimal AppView example
• “self-hosting entire bluesky” with docker-compose (including AppView, apparently)

as i wrote in another thread:

Content addressability is absolutely essential for building something that will last, and BlueSky gets that right. Decoupling the many responsibilities which an ActivityPub instance operator has (especially for identity) is also essential, i think, and while BlueSky’s identity solution is less than ideal it’s much better than ActivityPub and I expect it to improve.

If you’re interested in the topic you probably want to also read the followup post from the same author (after reading the reply linked there from someone on the BlueSky team).

Christine’s analysis is by far the best I’ve read on the topic, but I think she is too dismissive of the possibility that people will actually build things using ATP in a manner more like ActivityPub (where there doesn’t need to be a global view). It’s also possible/likely that ActivityPub will eventually evolve to adopt content addressability (Christine actually built a proof-of-concept of doing that years ago, linked in her blog post, but there doesn’t appear to be any recent progress in that direction), and decouple identity from responsibility for data availability, and adopt something like BlueSky’s composable moderation.

Given their respective advantages over the other, i’m pretty sure that both ATP and AP will make changes which make them more like the other in the coming years.

in what sense

Reading through it, I’m not seeing much in favor of ATP

See the “BlueSky’s strengths” section, particularly the last paragraph of it. Content addressability is absolutely essential for building something that will last, and BlueSky gets that right. Decoupling the many responsibilities which an ActivityPub instance operator has (especially for identity) is also essential, i think, and while BlueSky’s identity solution is less than ideal it’s much better than ActivityPub and I expect it to improve.

If you’re interested in the topic you probably want to also read the followup post from the same author (after reading the linked reply from someone on the BlueSky team).

Christine’s analysis is by far the best I’ve read on the topic, but I think she is too dismissive of the possibility that people will actually build things using ATP in a manner more like ActivityPub (where there doesn’t need to be a global view). It’s also possible/likely that ActivityPub will eventually evolve to adopt content addressability (Christine actually built a proof-of-concept of doing that years ago, linked in her blog post, but there doesn’t appear to be any recent progress in that direction), and decouple identity from responsibility for data availability, and adopt something like BlueSky’s composable moderation.

Given their respective advantages over the other, i’m pretty sure that both ATP and AP will make changes which make them more like the other in the coming years.

The Pi is definitely running Avahi and spamming multicast, when it attempts to resolve .local, it sends out multicast and unicast simultaneously, even with freshly flushed DNS cache.

I owe you an apology - I see now that my avahi systems are in fact also sending unicast SOA? local. when I resolve a .local name, and presumably if my recursor told them it was responsible for it instead of NXDomain then I would resolve names through it.

I was pretty sure that it doesn’t do that, but before telling you that it doesn’t I actually did a test and ran tcpdump -ni any port 53 or port 5353 while resolving some .local names. i even noticed that there was that SOA query being sent to and from localhost (to systemd-resolved) but I saw no answer to it and figured that systemd-resolved was the thing silently ignoring that TLD. But: it turns out that the system I tested on has its systemd-resolved configured for DNSOverTLS so I wasn’t seeing those SOA queries being sent on to the recursor on a different port 🤦

Sorry!

It does seem to me like a regrettable choice of the RFC authors to allow both, though, as it is easy to accidentally have a situation where the recursor and mDNS return different answers which would lead to inconsistent results when querying both in parallel.

why bother opening a pathway in the first place

i’ve never had an IG account myself, but i think your mistake is in assuming that someone accepting your follow request on a restricted IG account is an indicator of desire for chatting with strangers. accepting your follow request might just mean they glanced at your profile and assessed that you aren’t a spammer or bot, not that they want to chat with you.

perhaps just need to find out somewhere in the real world where I could bond more easily with real people?

for sure that is a good idea 😂

but there are also many places online where it is much more reasonable to assume people are interested in chatting with strangers.

Yes. It was even the suggested practice at one time:

https://en.m.wikipedia.org/wiki/.local

Cool, I didn’t know that. But the article also says they recommend against it now. I see the “Microsoft recommendations” section of the wikipedia article indicates they changed their mind on this several times.

On the other hand almost nothing uses mDNS.

In my experience mDNS seems ubiquitous; almost every network connected device I’ve seen in the last couple decades has it enabled by default.

Fucking bootcampers istg I’m so glad I don’t have to work with y’all and only interact when you deliver my fucking takeaway.

Huh? What are “bootcampers”? It used to refer to people running windows on intel macs (because apple’s boot loader to allow that was called BootCamp), but that wouldn’t make any sense in this context. Unless you are having your food delivered by people who run Windows on old Apple hardware? 🤔

Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion

So actually the RFC does not limit whatsoever the resolution of .local domains to mDNS. Implementers, apart from Android do indeed always do look up via both unicast and multicast (if not disabled). Only android limits this to multicast-only.

I see. Sorry I missed that part of the RFC.

But, FYI, it is really not only Android that doesn’t send unicast queries for .local names; GNU/Linux distributions running avahi (eg, the distros most people use) also don’t. I don’t have a mac or iphone nearby to confirm but I would assume they are probably resolving .local exclusively via mDNS too. edit: this “Apple devices might not open your internal network’s ‘.local’ domain” support article indicates my assumption is probably correct.

Also, please don’t tell people to KYS :(

In my opinion, yes, the why does in fact matter. This blog post i’ve linked in other comments in this thread is by one of the authors of the ActivityPub spec. If you care enough to comment about it i recommend reading her analysis of what AT Proto gets right and wrong in comparison with ActivityPub.

but you have to question why they’re choosing to reinvent the wheel

you don’t have to wonder why if you take the time to read about why; see the links in my other comments in this thread if you’re curious.

Is there any instance other than Bluesky where people can register?

There aren’t “instances” in the ActivityPub sense, where “instance” means single point of failure you’re married to (its name is literally part of your identity) which is simultaneously responsible for keeping your data available and curating your view of the rest of the network; AT Protocol decomposes these responsibilities so that they can be delegated independently to different operators.

See https://docs.bsky.app/docs/advanced-guides/federation-architecture and https://dustycloud.org/blog/how-decentralized-is-bluesky/ for details.

There are many people running their own Personal Data Servers, AppViews, Labelers, and Feed Generators, but I’m not aware of anybody else running a large-scale Relay yet (which is one of the things this new foundation says they are planning to work on). I’m also not sure if you can actually create a did:plc using a self-hosted AppView or if maybe you need to use did:web to create a new identity without using their AppView currently.

They mention ActivityPub in a few places, such as this blog post.

But I’d recommend https://dustycloud.org/blog/how-decentralized-is-bluesky/ instead, which is the best discussion I’ve seen so far of the pros and cons of each of the two approaches.

have you read about why they didn’t?