Technical details and the installer are in the GitHub repo https://github.com/bluesky-social/pds
And we're on Discord available to help: https://discord.com/invite/UWS6FFdhMe
Technical details and the installer are in the GitHub repo https://github.com/bluesky-social/pds
And we're on Discord available to help: https://discord.com/invite/UWS6FFdhMe
[1]https://www.emilydamstra.com/please-enough-dead-butterflies/
Are you joking? This is private enterprise we're talking about. We'll all die before this company or anything similar is built on "scientific rigor" unless it directly relates to their profit margins.
I didn't know this (as most of us I'd guess). It was an interesting read though, thanks.
Edit: now it has one! Thanks!
The on-demand TLS certificates with an "ask" endpoint is especially useful for the PDS use-case. Because there's generally a wildcard DNS name that is used to give each new user a domain handle (@alice.example.com) but we don't want to be vulnerable to a TLS certificate DoS/rate limit situation.
Love the fresh federated model btw!
https://news.ycombinator.com./
If you want a link to a page with a link like this you can click on the github issue I referenced in my original comment as there are links there like that.
If you want a more natural page that is less meta with such a link
https://jameswillia.ms/posts/shortest-urls.html
>Also, the term ‘FQDN’ does not always imply the dot at the end?
Yes, but if there is not a . at the end then there is ambiguity of if it is a FQDN or not.
And it's probably not niche if dozens of users are posting about it for years.
That doesn't change my point. I am pointing out a an easy pitfall Caddy users can fall in since it is not automatically handled for them as it is with other server software, nor is it pointed out in the documentation fkr Caddy. Simple server software would avoid these pitfalls automatically for users. So while it now be simple to get https working, properly configuring the server is now more complex to get right.
An intentional pitfall doesn't mean it isn't a pitfall.
I'd imagine this use case is quite common for self hosters. If it can't operate alongside an existing, say, nginx on this port, are there recommended alternate practices?
I'm excited at separating identity from hosting, of which self hosting identity gets us closer.
If it had been an opt-in system, the response would probably have been far different.
And someone else will just go build an opt-out (or maybe even no opt-out!) bridge.
And again, it wasn't about Bluesky in particular. If Google announced that they were going to ingest all Mastodon content and post it in a new Google Groups kind of thing, they'd be pretty understandably upset about that, too.
In general, "if I wanted my stuff on Bluesky, I would have put it there". It wasn't the bridge creator's decision to make.
In general, "I want my stuff on Bluesky but don't want to deal with cross-posting to multiple different platforms and keeping up with responses on all of them"
And, "I want my stuff on whatever platform people want to read it on without having to individually approve each one" (which is quite literally the entire point of public posts on Mastodon).
OH - and it wasn't the bridge creator's decision anyway; it was the decision of people on Bluesky to follow you that would trigger your posts to be federated, so...
Similarly, I don't want my blog posts used to train LLMs. I know they're likely to be since they're published right there on the Internet for anyone to see and read. But my intent was for other humans to see and read them, not for someone to feed them into a regurgitator. There aren't technical means that let me allow humans to read my stuff without allowing LLMs to ingest it, and someone could make the (bad) case that if I didn't want my work to be used to train an LLM, I shouldn't have made it public. Maybe. However, I reserve the right to think someone's an ass for doing it.
Well, no technical hurdles kept the person from copying data out of the network people meant to post it to. It's probably not illegal. It's not a nice thing to do, though.
Except literally the entire design is for other Mastodon servers to bulk copy it en masse to somewhere else.
> There aren't technical means that let me allow humans to read my stuff without allowing LLMs to ingest it
Yes there are. Don't make it public.
> However, I reserve the right to think someone's an ass for doing it.
Of course! You can think anyone is an ass. You can think anything you want. That doesn't mean that person did anything wrong.
How about "If I wanted my stuff on the your Mastodon server, I would have put it there"?
"If I wanted my Mastodon content on your RSS feed, I would have put it there".
How about "If I wanted my stuff on the Internet, a publicly available internet, I would have put it there".
This tribalism around network/brands/protocols is beyond stupid. The thing that is killing Twitter is its closedness and the assumption that the means of communication is what matters. It's not. Let open protocols be open.
If people want privacy, then they should use a secure communication protocol and not a social media network.
exactly like they did with usenet without any issue?
To make it clear, for people who don't know:
Google Groups was originally Dejanews, which was a web based archive and front end to Usenet. Google started searching Usenet, but didn't have historical archives so they bought Dejanews.
Obviously no one who posted on Usenet got paid under this transaction.
It's like if Google bought a Mastadon archive off someone now: this argument seems to indicate that would be better somehow than Google archiving Mastadon posts themselves.
I don't understand why at all?
I thought that was the point of activitypub.
The whole point of a fediverse is it's a federation. Therefore there is implied consent to copying from one instance to another.
> but the intent of posting to Mastodon isn't to have it show up automatically on another network
Mastodon isn't a network, the network is the fediverse. Mastodon is some software that runs on the network.
Mastodon is an odd sort of network, there's more blocking than I expected and it somehow seems as if blocking is an intrinsic part of the design. In Mastodon, blocking looks like a choice one makes for whatever reasons, not an unloved measure needed for fighting abuse.
As if the design doesn't tell users "you can follow people in the fediverse" but rather "your ability to follow people in the fediverse is limited by you and three other parties and the software isn't among the three".
So… if the mastodonish idea of consent doesn't extend to all of the fediverse, what makes bluesky different from some unvetted mastodon site run by weird people? If the poster's/follower's/would-be follower's consent isn't taken for granted in one case and isn't taken for granted in the other, what makes the two cases different? There obviously is a technical difference, but what is the difference wrt. consent?
Absolutely nothing! Fediverse admins block unmoderated sites all the time, for being unmoderated. Bluesky is just, effectively, one unmoderated instance that everyone will block by default.
Except that's not what the bridge does, at all. It only follows you on someone's behalf when someone on Bluesky specifically requests to follow you through the bridge.
Why are Fediverse people only angry about it now? It's an open protocol. If you want privacy, don't publish something for the entire world to see. That's just basic common sense. At the very least, use Mastodon's privacy controls. The Fediverse is not special here, it doesn't get to destroy the open Web for everyone else.
As for the fediverse destroying the open web for everyone else, I think you’re hyperboling quite a bit, the fediverse has done mountains to make social media more open, probably more than everyone else.
Though I think "voicing concerns" is a bit of an understatement. I feel really bad for the developer of Bridgy Fed, working on their passion project and just getting caught up in all this heat and harassment.
It's the same situation with Threads.
As for privacy I disagree with you. There's nothing because nothing has been discussed, but the technical feasability should never dictate what we want as a society. When a family member dies, even though the news is known you know how to behave, who to share that information with, what to say. Would you be okay with a company coring up to you and saying "hey we learned your mother died, would you like to tweet it ? It is free !"
But it's not never. For example, I can see your post. So I can send a screenshot of your post to my friends to dicuss it. I can't see your hard drive contents. So I shouldn't hack into it and send a screenshot of your hard drive to my friends to discuss it.
So technical feasibility influences what is reasonable to do as a society. It's not "feasible = reasonable", or else murder would be reasonable, but it definitely does influence it.
And in this case, I believe what the Fediverse people commenting in the GitHub issue want to be unreasonable. It is unreasonable to publish something publicly, on a federated network, where privacy controls exist (but are not being used), and then claim to have an expectation of privacy in a public space, especially when such bridges provide utility and benefit to others that just can't happen if it's opt-in.
It is reasonable to block it. It is unreasonable to expect everyone else to restrain themselves from using public data in the spirit of the open Internet. It is especially unreasonable to harass non-profit bridge developers in this case. That's not a social solution, just harassment.
Note about copyright: that's not a path one should go down, because it'll make the Fediverse illegal as a whole. It's probably fair use, anyway.
Note about AT protocol: yes it's designed by a for-profit, but it's good. Just because something is for-profit and VC-backed does not mean it will enshittify; take Element for example. It solves a lot of issues that people were having with Mastodon such as global full text search and a global feed. I would use it if it only had more relays to spread out the control.
As a controversy, it's been blown out of proportion. It's just Fediverse admins setting the moderation policies for their own sites, as always.
Does the AT Protocol only optimize for Twitter-like flows, or does it allow for other types of social applications to be built like Activitypub? For example a reddit-like social media.
Part of the change today is that the PDS and Relay[1] now support non-app.bsky record types. This is quite new, so there could be issues, but we're prepared to fix any issues that crop up.
1. https://bsky.social/about/blog/5-5-2023-federation-architect...
Would it be possible to use it for macroblogging, i.e. long posts with markdown markup, embedded images, etc? If so is there a python library tghat implements atproto?
Another really neat aspect of atproto, is that apps can interact theoretically. So you might create a blog system but use "app.bsky" (Bluesky) for comments.
OAuth support is coming soon as well, which is a big step in simplifying auth.
Yes, it's totally up to a PDS operator to decide how they create user accounts. It's also not required on the Bluesky PDS service any longer, in most cases.
By default the self-hosted PDS requires an invite code, to prevent random people from creating an account. Later other options will exist, including OAuth support which is coming soon.
> It's also not required on the Bluesky service any longer, in most cases.
That's also nice to hear - when last time I tried to register an account (shortly after the free registration launch) the phone number field in the registration form was marked as required, if I am not mistaken.
There is a Docker compose file in the repo, and advanced users shouldn't have any problems running the code on another distribution or even without Docker if they prefer.
Advanced users can just view the installer script as documentation.
Very cool to see this available though, I might have to try it out later this week!
There's an (incomplete) list here: https://docs.bsky.app/showcase
And the protocol is documented here: https://atproto.com
My question was motivated by the fact that from the outside the AT proto ecosystem looks pretty monocultural, and personally I don't trust that. :)
Basically, you're right, but just because you're asking early on. This is about to change real quick.
I'm contrasting this through the prism of having seen people implementing ActivityPub software as early as 2017, when it was merely a draft and everyone was complaining about how many things had been left out.
I use BSD, and all I see is a installer for Debian/Ubuntu.
No guide in sight for bare metal nor telling you what services/software are required.
Also, services like Twitter started off with a developer friendly open API, and then it got closed off when the business needed to make money off the platform. What's the difference with Bluesky?
It's MIT/Apache 2.0 licensed, so yes. However, because it's also an open protocol, even if it wasn't, you could write your own under whatever license you want.
> What's the difference with Bluesky?
BlueSky is built off of an open protocol, called AT. https://atproto.com/ BlueSky is a particular app built on the protocol. As such, there's no way to "turn off the API," as BlueSky itself is a participant in the open protocol.
They could like, re-write everything to be a central service, port the user data over to it, and then pull out from the network, but then two things would happen:
1. stuff would break, as it's no longer part of the network.
2. since there is true account portability, users could simply swap to a different PDS and client, and re-route around the damage.
Also given that it's against their entire stated mission and goals, it would be social suicide.
When I was thinking about rolling my own federated social service (during the whole Twitter / Mastodon shuffle), I started thinking about the negative impacts of federation. “How can I build a kill switch into this thing in case bad actors start to participate?”
Of course, that means a central authority having moderation control.
But then, part of me thought.. does there need to be a kill switch? Do we want centralized moderation control? If laws are being broken, or social issues are being pressed to the fringe (*lons X), then the ISP would intervene. Or… the responsibility of moderation shifts elsewhere than the provider of the software. (To where do moderation responsibilities shift, if anywhere? I think is still a question.)
I personally landed at the spot of: it’s really no different than what the WWW provides — it’s just easier access. But, is that easier access to self host content and media dangerous? (lol I guess I’m still conflicted about what could happen with wider ease-of-access to self hosting.)
… back to sleep. This stuff literally keeps me up at night lol
(I didn’t get to the other comments further down in this post that talk about content moderation .. but I’m seeing them now!)
I'm working on a client and there's a specific scenario where I want to be able to show a feed like "Top 20 - Past 3 Hours" before a user has logged in to their Bluesky account.
Any chance the team could create a Home Assistant add-on for this? https://www.home-assistant.io/addons/
I think the Home Assistant community would go WILD for being able to self-host their Bluesky data straight from home with just a few clicks.
It's a pretty big crowd of people. https://analytics.home-assistant.io/ 327k willing to opt-in to analytics.
I know if there's one thing I'm eager to do it's to host even more stuff in that clunky piece of shit that has half a dozen main menu items for nonsense and buries everything of interest or value under "Settings"
It's wasteful to get an entire second machine for something that can use the resources available on the machine running Home Assistant OS