Rendered at 20:37:34 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
simonw 19 hours ago [-]
The original Jetstream is really cool - it's incredibly easy to start consuming the Bluesky firehose - you don't even need to use a server, you can consume it directly in the browser.
Every move/zoom in the map causes it to pollute the browser history. You might want to fix that.
delfinom 5 hours ago [-]
Chrome Windows, zoomed in on paris, france. Click the restaurant filter for search. The tab froze, tried multiple times. :3
maelito 3 hours ago [-]
Thanks ! It's the densest place in the world for restaurants. We're working on a v2 of place search by category, soon to come.
Google's task is much easier on this one : they only show those who've paid ads at high zoom (well at least, that's what we can guess). We're trying to be exaustive, but it's too much in this case.
josephg 19 hours ago [-]
I wonder if it would be a good idea to remake DNS on top of bluesky. The basic idea is that, if you own a domain name, you post DNS updates in a bluesky feed. The firehose itself is authoritative. DNS servers sit downstream of the firehose. All the updates to domain names get written into a database, and they essentially just respond to queries hitting that database. This would let anyone (with enough bandwidth) run a fast domain name server.
We could use this to fix some of DNS's long running problems. Like, we could add upstream cryptographic signatures to DNS records. And put TLS certificates in there too. We might be able to ditch TTL entries. In a DNS server, records should update via server-push from the firehose. You shouldn't have to wait for TTL to expire.
I think it'd make a nice little system.
arjvik 19 hours ago [-]
I think you just invented blockchain DNS (e.g. https://handshake.org/) without the byzantine tolerance.
josephg 18 hours ago [-]
Yes, exactly. Blockchain DNS minus the blockchain is just good DNS.
vvpan 17 hours ago [-]
Blockchain has some solid properties, don't throw the baby out with the bathwater.
josephg 16 hours ago [-]
What baby? DNS doesn't have the double spend problem. Why is the blockchain good for this?
inigyou 10 hours ago [-]
The double spend problem for domains is the double domain purchase problem. I claim example.com and you also claim it, who wins?
josephg 8 hours ago [-]
Whoever buys it first. With a centralised database, this is trivial.
Usernames are the same. Who gets @example.bsky.social ? Whoever registers it first. Problem solved.
pineapplepizza6 7 hours ago [-]
If you have a central database why do you need atproto?
josephg 13 minutes ago [-]
To stream dns changes from site owners to dns servers. If you want to change a record, you post the change on atproto. DNS servers everywhere just subscribe to the jetstream. That way anyone can run a fast, local dns server which is kept up to date automatically.
adinisom 5 hours ago [-]
I'd like to see DNS ownership combined with the time range and an owner-unique key so you can go to the website you intended to visit rather than whoever happens to own the domain at the moment.
rswail 13 hours ago [-]
An authenticated chain similar to the crts for TLS certificates.
josephg 8 minutes ago [-]
You don’t need a blockchain to implement a cryptographic chain of trust.
tancop 8 hours ago [-]
[dead]
inigyou 12 hours ago [-]
How do you prove you own a domain with no records?
josephg 7 hours ago [-]
We’d need a registry of some sort. And a name space. Register a name, associated to a Bluesky account. Then use that Bluesky account to update dns records.
lvbyte 7 hours ago [-]
[dead]
geoah 7 hours ago [-]
I'm trying to work out how the OP's system would look like and I was wondering the same.
---
There are at least three parts that you'd need to solve:
1. AFAIK there is no single globally canonical Firehose. Different relays aggregate different sets of PDSes, and some might decide not to include your PDS if they don't like your content. The Firehose also isn't really the authority here. It transports signed updates from account repositories.
2. In theory you could make up a new kind of DNS record instead of NS, called PDS, PLC, or something. You'd ask your TLD registry to publish something like `PLC <did>` instead of the NS records for your DNS server.
The value should probably be the account DID (that's the PLC mentioned above), rather than the address of its PDS. The account DID is the stable identity that signs the repository updates. The PDS is just the server currently hosting that account's repository, and its address can change.
3. You then have a bootstrap problem. To get from an account DID to its PDS, you resolve the DID document and look for its `#atproto_pds` service entry. But `did:web` resolution uses HTTPS and therefore DNS. `did:plc` uses the PLC directory, but reaching that directory and then reaching the PDS URL also normally requires DNS.
So the DNS replacement would depend on the old DNS system to discover the server containing its DNS records.
---
Then, as an example, Google's DNS resolver at 8.8.8.8 would subscribe to one or more Firehoses, index DNS records from account repositories, and verify that their updates were signed by the DID named in the registry record.
Querying would then be something like: you look at the top-level record for the domain, see that there is no NS entry, find the PDS or DID entry, and look in your local Firehose-derived database for DNS entries signed by that account.
If the records aren't there, you might resolve the DID, find the current PDS, and fetch the repository directly. But that brings you back to the bootstrap problem.
Maybe the registry record would need to include both the DID and some kind of glue-like PDS address. Or perhaps the new system would need an independent way of resolving DIDs and locating PDSes without using DNS. I'm not sure what that would look like, especially once you include PDS migration and key rotation, but I think this is an additional part the proposal would need to solve.
/shrug
ruined 16 hours ago [-]
this is not quite what you are asking for but https://marque.at exists
inigyou 10 hours ago [-]
No A, no B. It's not X, it's Y.
walrus01 20 hours ago [-]
Sort of on a tangent to the actual content of the page, but what documentation system/CMS is this particular web page UI? It seems very fast and relatively uncluttered for the menu on the left side, content pane, top horizontal menu bar.
If I'm understanding this codebase right, it's a hand-rolled framework based on MDX and Next.js; the UI elements you're referring to were designed from scratch and aren't based on any existing CMS theme.
walrus01 19 hours ago [-]
Some of it looks like tailwind css and they have a syntax highlighting addon that shows up in the homepage source as well.
someothherguyy 19 hours ago [-]
some modified vercel template by the looks of it
VorpalWay 20 hours ago [-]
No sure I agree on fast. At least on mobile the sidebar has an show/hide slide animation that takes a sizeable fraction of a second. In fact is one of the slowest animations for this I have seen.
I disable animations entirely on devices I use where possible. They just waste time and that adds up if you use something regularly.
walrus01 20 hours ago [-]
I haven't looked at it on mobile, that's unfortunate to hear. I don't see any animation when interacting with it on a desktop browser, snapping open a left side header menu item to see sub-items seems instant.
VorpalWay 20 hours ago [-]
I meant showing/hiding the side bar itself, not headings in it. Using the triple dash menu button in the top left corner.
walrus01 19 hours ago [-]
Yeah, I see what you mean now, I am looking at it on mobile and that animated slider to show or hide the entire menu seems like it takes unnecessarily long.
VorpalWay 18 hours ago [-]
Indeed, and any animation at all is too long for UI elements in my opinion.
eviks 13 hours ago [-]
It should take time for you too appreciate the main text becoming blurry and unreadable and to prepare your brain for the new batch of text
Melatonic 4 hours ago [-]
Agreed. Is there an easy way besides the simple OS feature ?
phoghed 19 hours ago [-]
Gonna go out on a limb here and say css transitions are not what they are talking about.
arikrahman 12 hours ago [-]
Looks like astro starlight
notpushkin 12 hours ago [-]
There’s a next-route-announcer tag on the page, so probably not Astro. (Can’t recommend Astro Starlight enough though!)
taylorbuley 5 hours ago [-]
This protocol would be a great match for UCAN.
ChrisArchitect 19 hours ago [-]
Suppose this would be an example of what they meant by 'expands beyond the app'
Related:
Bluesky's active user base is shrinking as its focus expands beyond the app
Do you have a database/ui of all of this story graph labeling you've done? Is there a story behind it?
ChrisArchitect 19 hours ago [-]
I'm all for whatever atproto expansion and whatever's going on here, mainly it harks back to early Twitter days (tho also for better or worse, watching them build Bluesky in realtime isn't the best), but when they have outages like last week a good chunk of service unreachable/down for many hours with little update on https://status.bsky.app/ and then whatever history just basically disappears as if nothing ever goes wrong, it's not a good vibe.
Despite all the openness and github repos and what not it's very difficult to get straight answers or just like find a place where issues or changes to the platform are addressed easily.
anal_reactor 13 hours ago [-]
I've built my own client for Twitter. I'm using a library that a random guy maintains. It has its problems, but all of them can be worked around, and overall it feels solid, especially considering the fact that it's done by a single person.
Then I had to add bsky support when everyone and their mother migrared there. I used the atproto Python library and holy smokes, whener I need to touch that part of the code I feel sad.
inigyou 10 hours ago [-]
I suppose that while your Twitter thing just touches the surface-level client-facing API, your Bluesky thing touches the internals. You could scrape bsky.app the same way you do for Twitter.
boramalper 13 hours ago [-]
> I've built my own client for Twitter.
Didn't they terminate free API access? How does your client work?
gkbrk 13 hours ago [-]
It still has an internal GraphQL API. How would the official web app and mobile apps work without an API?
afavour 10 hours ago [-]
Right but that doesn’t mean anything about authorisation. If you’re using a key you ripped from an official app you could easily be blocked tomorrow. Makes the effort considerably less worthwhile.
gkbrk 10 hours ago [-]
It's the #6 most popular website in the world. Chances are, someone will fix the libraries or investigate and write about any changes done to the internal API pretty quickly.
inigyou 10 hours ago [-]
Then you rip the key again from the new version of the app. But they won't do that because it would block the app.
8 hours ago [-]
GaryNumanVevo 10 hours ago [-]
As a researcher who spent most of my graduate program trying to scrape twitter to do sentiment analysis. I do not believe you.
lorreyfum 7 hours ago [-]
[dead]
readabilitylab 19 hours ago [-]
[dead]
masc4masc 18 hours ago [-]
[dead]
simonnw 6 hours ago [-]
[flagged]
LAC-Tech 19 hours ago [-]
[flagged]
twotwigs 18 hours ago [-]
[flagged]
vvpan 17 hours ago [-]
What is the problem?
myshapeprotocol 9 hours ago [-]
[flagged]
api 9 hours ago [-]
Is it actually decentralized or is bluesky protocol services in the middle?
Even from the comments, they just don’t have the right base. Such a shame.
erryy 13 hours ago [-]
Neat protocol, shame about the users.
Also the VC-backed funding for this infrastructure will run out eventually. It's not self-sustaining, and Bluesky have no viable route to profitability.
Gareth321 11 hours ago [-]
[Bluesky proves that for social media, no matter what your technology stack, capabilities, or mission, if your community is awful, growth will never follow.](https://blueskyfeeds.com/bluesky-user-growth?t=3m)
krige 10 hours ago [-]
Twitter seemed to have no issue growing so that doesn't seem right.
eviks 9 hours ago [-]
> no matter what your technology stack, capabilities
We haven't had many of the good sets of these to get any proof
afavour 10 hours ago [-]
> shame about the users
I use Bluesky regularly and have a fine experience. Yes, there’s an irritating minority of users. But so goes any social network, Twitter especially. At least the owners of Bluesky aren’t espousing Great Replacement Theory…
lou1306 10 hours ago [-]
I also have a fine experience, but only by switching to the For You feed full-time and mostly sticking to my compsci-academic-tech-programming neck of the woods. Minority or not, the users GP mentions are so obnoxious that it affects the 'vibe' of the platform as a whole. Look up any "Top Posts" tracker/feed/whatever. No matter that I even (mostly) resonate with the underlying political leanings, I find the tone pretty dreadful.
Of course, the same applies to whatever remains of Twitter now.
W3cUYxYwmXb5c 7 hours ago [-]
Yeah, it's nothing against the platform itself, it just happened to get a population boost from dissatisfied people. It seems so many of them are just miserable and there to create a feedback loop of negativity.
afavour 6 hours ago [-]
> Of course, the same applies to whatever remains of Twitter now.
I think that’s the key of it for me. Usually this criticism of Bluesky users is part of a justification to stay on Twitter. When the exact same problem exists on there, just with a different type of user.
I updated my browser demo to use the new Jetstream just now - hit "connect" and scroll down the page to see the events flowing past: https://tools.simonwillison.net/bluesky-firehose
This is new jetstream:
wss://jetstream.us-east.bsky.network/subscribe
In case of data loss, replaying the jetstream was not possible. This v2 with history is perfect.
* https://cartes.app
Google's task is much easier on this one : they only show those who've paid ads at high zoom (well at least, that's what we can guess). We're trying to be exaustive, but it's too much in this case.
We could use this to fix some of DNS's long running problems. Like, we could add upstream cryptographic signatures to DNS records. And put TLS certificates in there too. We might be able to ditch TTL entries. In a DNS server, records should update via server-push from the firehose. You shouldn't have to wait for TTL to expire.
I think it'd make a nice little system.
Usernames are the same. Who gets @example.bsky.social ? Whoever registers it first. Problem solved.
---
There are at least three parts that you'd need to solve:
1. AFAIK there is no single globally canonical Firehose. Different relays aggregate different sets of PDSes, and some might decide not to include your PDS if they don't like your content. The Firehose also isn't really the authority here. It transports signed updates from account repositories.
2. In theory you could make up a new kind of DNS record instead of NS, called PDS, PLC, or something. You'd ask your TLD registry to publish something like `PLC <did>` instead of the NS records for your DNS server.
The value should probably be the account DID (that's the PLC mentioned above), rather than the address of its PDS. The account DID is the stable identity that signs the repository updates. The PDS is just the server currently hosting that account's repository, and its address can change.
3. You then have a bootstrap problem. To get from an account DID to its PDS, you resolve the DID document and look for its `#atproto_pds` service entry. But `did:web` resolution uses HTTPS and therefore DNS. `did:plc` uses the PLC directory, but reaching that directory and then reaching the PDS URL also normally requires DNS.
So the DNS replacement would depend on the old DNS system to discover the server containing its DNS records.
---
Then, as an example, Google's DNS resolver at 8.8.8.8 would subscribe to one or more Firehoses, index DNS records from account repositories, and verify that their updates were signed by the DID named in the registry record.
Querying would then be something like: you look at the top-level record for the domain, see that there is no NS entry, find the PDS or DID entry, and look in your local Firehose-derived database for DNS entries signed by that account.
If the records aren't there, you might resolve the DID, find the current PDS, and fetch the repository directly. But that brings you back to the bootstrap problem.
Maybe the registry record would need to include both the DID and some kind of glue-like PDS address. Or perhaps the new system would need an independent way of resolving DIDs and locating PDSes without using DNS. I'm not sure what that would look like, especially once you include PDS migration and key rotation, but I think this is an additional part the proposal would need to solve.
/shrug
If I'm understanding this codebase right, it's a hand-rolled framework based on MDX and Next.js; the UI elements you're referring to were designed from scratch and aren't based on any existing CMS theme.
I disable animations entirely on devices I use where possible. They just waste time and that adds up if you use something regularly.
Related:
Bluesky's active user base is shrinking as its focus expands beyond the app
https://news.ycombinator.com/item?id=49263461
Despite all the openness and github repos and what not it's very difficult to get straight answers or just like find a place where issues or changes to the platform are addressed easily.
Then I had to add bsky support when everyone and their mother migrared there. I used the atproto Python library and holy smokes, whener I need to touch that part of the code I feel sad.
Didn't they terminate free API access? How does your client work?
Also the VC-backed funding for this infrastructure will run out eventually. It's not self-sustaining, and Bluesky have no viable route to profitability.
We haven't had many of the good sets of these to get any proof
I use Bluesky regularly and have a fine experience. Yes, there’s an irritating minority of users. But so goes any social network, Twitter especially. At least the owners of Bluesky aren’t espousing Great Replacement Theory…
Of course, the same applies to whatever remains of Twitter now.
I think that’s the key of it for me. Usually this criticism of Bluesky users is part of a justification to stay on Twitter. When the exact same problem exists on there, just with a different type of user.