whyrusleeping

Cheaper than it is now! I think it was about $1100 at the time, definitely the most expensive part of the whole setup

I've also done a full network replica (all the data indexed in a postgres) on a raspberry pi (with an 8tb nvme attached via a hat). Its really not expensive to do . And if I wanted to drop data older than say 3 months, it would be even cheaper still.

The default pds packaging takes care of SSL, but thats not a requirement, just something we try to make easy for users.

Also at:// URIs are of the form at://DID/..., and your human readable handle is bound to your DID through DNS TXT records _atproto.roshangeorge.dev, but applications all know to render that as just roshangeorge.dev. That DID points to a document that specifies where your server lives, so the HTTPS/WSS routes can live wherever you want them to.

Also likes/replies/etc on your posts go in their authors repos not yours, your intuition is correct there.

people get so up in arms when you suggest there might be a limit on how many people they can follow.

fwiw, the Knuth quote is "premature optimizations are the root of all evil"

I tend to agree with this, thats why theres canonical URIs for atproto posts that are agnostic to the hosting provider. The format is at://DID/collection/recordKey.

These are used throughout the system, for example if you look at the output of a feed generator, its just a list of these URIs

It's possible, and we've talked about it, but it would take a good amount of work (as would any 'correct' solution), so we have punted on properly solving DMs for a bit. I know Matthew has been very interested in working with us to figure something out here

My assumption for this being proprietary is so that it cannot be gamed. It could be a darker reason, I suppose.

As the guy developing said feed, this is indeed the reason. I have a hard enough time as it is with people gaming the specific parameters of the feed, having it fully open would be a huge tax on my time.

Most of the components of the feed are trialed in my personal feeds repo here: https://github.com/whyrusleeping/algoz

You could take the code from there and get to a workable "Discover" feed relatively quickly if you wanted to. Also several of the feeds I have in that repo are among the most popular feeds in the network, especially Quiet Posters (infrequent.go).

its been consistent around 10/s most of today, hit even higher bursts at points. Its been steadily increasing every day for the past week.

It is indeed an open source app for an open source protocol.

yeah it works fine on bare metal, you'll just have to do a bit more set up work yourself (https terminating and such). The installer script should be instructive in how to run it but you'll have to figure out the BSD specific stuff

currently we support ed25519 and secp256k1 for signing, adding more key types isnt terribly hard, but does require coordination (everyone has to support it otherwise posts signed with that key type won't get propagated)

The most straightforward way to fully use the network without trusting us at all would be to have your identity backed by a did:web, and run your own PDS. From there your posts will be indexed by our appView and you can see them in the app. If you still don't trust our AppView to show you the right thing, you can definitely run your own (its a little hefty and requires indexing the whole network). Beyond that, if you don't trust our relay to feed your AppView, you can run your own and have it scrape all the PDSs (the endpoints for this are open on each individual PDS). At that point the app experience for you should be roughly equivalent (depending on how you choose to apply moderation actions) without using any of our infrastructure. You would still be able to interact with everyone, all your followers can still see your posts, and no normal users would notice you werent on the same servers as them.

"Kinda" and "Soon", the soon part is that interactions with the site are signed by a key thats usually held for you by your PDS (Personal Data Server), this month we are opening things up more so you can run your own PDS, and thus use your own keys.

The Kinda part is that your identity by default is backed by a DID that delegates authority to specific keypairs. The keypair that your PDS uses to sign is included in there automatically, but on account creation you can currently set a backup keypair that allows you to manually sign identity operations.

happy to answer any questions people might have about custom feeds, the post linked above is me

While individual posts are not self-authenticating (largely because it makes deletion much more complicated) all of a users posts are in a merkle-tree that it itself self-authenticating. A Post and the merkle-proof to the root its a complete verifiable entity.

all modern server CPUs have intrinsics for sha256, it just doesnt matter CPU-wise

no this actually is moving every single user currently on the service into this setup. Everyone gets their own sqlite under the hood.

The incremental requests are verified if running through your own node as a side effect of loading the data

While I totally get where you’re coming from, its a bit of an unfair question, “how are you going to do the thing you are attempting to do??” Is hard to answer without just saying “watch and see”, but ill try.

From a technical perspective the architecture is very similar to Twitter or other social networks internally, just pieced apart with some cryptography added to allow different components to not have to fully trust eachother. Thats to say, the components individually scale the same as twitter does (probably better tbh, we’re building this with 2023 tech not 2005 tech). Im happy to dive into that more but I actually dont think the technology is the hard part.

The bulk of the work is culture and community building and maintenance. One of the biggest things we’ve been focused on getting right is moderation, and the federated architecture helps a lot here. Allowing “third party” labeling to be integrated into the experience seamlessly allows communities to choose their own way of curating their experience. Instead of relying on a single company to dictate “the rules” you just pick “the rules” you want and go from there. There’s obviously a lot more to it, so id encourage you to check out some of our other blog posts: https://blueskyweb.xyz/blog

Hi, i'm the guy who built IPFS and Filecoin which are moderately large decentralized networks, and both me and Martin Kleppmann are technical advisors to the project. Additionally, Jeremie Miller (of XMPP) is on the board. The core team consists of developers who have many years of experience working on decentralized technologies (Jay, Paul, and Daniel have been in that space for a long time) and the others have plenty of other relevant experience (Including Docker and the Internet Archive).

Sure, nobody has ever built a decentralized social network at scale before, but we're not blundering our way into this.

pretty far down in the thread, hope no-one but you sees this: bsky-social-fupii-zizug

its currently an invite-only beta, but i feel like we've dealt with worse randos than late night hacker news commenters, so here you go: bsky-social-55rkz-5aago

https://twitter.com/arcalinea/status/1583231719943327744

Hello Fellow Internet User, In general, it is your own responsibility to keep yourself informed when commenting on something. The World Wide Web makes this easy with something called a 'hyperlink', for example, the one at the top of the article you read that says 'blog': https://blueskyweb.xyz/blog

downdetector just uses search trends from google and twitter and other social apps, its definitely not checking if the site is 'down' on its own.

Activitypub is a pretty dated standard thats really not super easy to work with or adapt to a more open network. Its an XML based protocol that bakes in really difficult to use notions of identity and doesn't address the problem of data ownership in a meaningful way. From what I've been seeing, the bluesky team has been working closely with the activitypub developers on figuring out 'what comes next'.

I assume you havent seen https://twitter.com/bluesky ?

GrapheneOS is compatible with several Google Pixel smartphones.

That doesn't bode well for things working all that well. As someone who ran linux on chromebook for two years, then on a macbook for three, i'm a bit burnt out on this sort of thing.

People are working on smaller unixy tools to do fewer things well, but at least for the main codebase we are limited by go itself. Making binaries smaller is not simple at all...

You might be interested in checking out the rust implementation: https://github.com/rs-ipfs/rust-ipfs

Im not actually sure how well it would work for what youre after, but it is an option!