Even framing it as 'account portability' is missing the point. I want to own my identity and take it with me anywhere. I shouldn't need to transfer anything, its mine. This model is fundamentally incompatible with how ActivityPub works (no, running your own server is not the same thing as decoupling identity from the concept of a server itself.) Could that change in the future? Maybe, but not without prior art. Even if you think @proto, farcaster, ssb, nostr, or others are doomed, we should be applauding them for attempting to push the needle forward.
It's weird to me that all the complaints about @proto being NIH focus on ActivityPub when if anything it's closer to an evolution of secure scuttlebutt. The two are so fundamentally different I do not understand the complaints.
Trucks and bicycles are just proxies for the broader culture war. As some one who likes trucks AND rides bicycles, I'm used to getting massive amounts of hate from both sides lol.
No, I don't need volume. I want to haul things that I do not want inside of the cabin (trash, dirt, gravel, wild game, dirty camping equipment, muddy boots, etc.)
I would trade in my model y for a compact electric truck of similar spec and price if it existed. I live in a city and don't haul stuff most of the time, but every time I need to carry trash or dirt, make home depot runs, or move furniture I wish I had a truck.
Consensus isn't a fundamental requirement for social media or a communication protocol. Email doesn't require a blockchain and doesn't care about 'double spending' or whatever.
As someone who uses nix daily for work and home, I've found that there is always a nice concise way to accomplish what I want, but finding that solution is extremely difficult. It seems like the best (and sometimes only) documentation is the code itself, so until you get comfortable with the language you are missing a majority of the documentation. It's a catch-22, you have to know nix to learn nix. It really shouldn't have to be that way.
I'm not against public schooling in principle but its current form is baffling. We expect kids to spend 1/4 of their entire life in an authoritarian system where they have no autonomy and then we throw them to the wolves when they become adults.
Maybe its incumbent automakers finally ramping up the competition and putting electric vehicles on the road. Telsa has probably been overvalued for a while and needed to come back to earth but between their R&D and massive lead in charging networks I still think they have a bright future. I think the R1T is the coolest truck on the market right now and the R1S is my most desired suv but now that all of the incumbents are starting to ship electric trucks its going to be hard for them to compete. Those vehicles are like $100k+ with a reasonable configuration. I don't understand Lucid at all.
I do the same thing. The only inconvenience is it adds an extra step when you want to watch something after your subscription runs out (resume the subscription and cancel). Google play and the app store make this super easy.
We are using nextjs for everything it can do, while bypassing it for the things it can't. With 13.1 that shouldn't be necessary because it is now more capable.
This sums up my feelings about the js ecosystem entirely. Lots of growing pains.
I've felt for a long time that every industry shift on the long road from simple server-side rendered monoliths to client-side heavy js SPAs we have taken a step forward in what is possible while taking multiple steps back in so many other dimensions (simplicity, security, dx, etc.) I think by the end we will be in a better place across all of these but it feels like we have been crawling out of a hole we dug ourselves to get there.
The nextjs team for the longest time seemed openly hostile to server-side features in the GitHub issues. We ended up using the custom server feature to essentially bypass nextjs entirely so we could adequately do things like server-side auth in an explicit way using existing proven middleware. Next auth was inadequate for us mostly because of the limitations of nextjs itself. Nextjs 13.1 just added actual server-side middleware with full control of requests/responses so hopefully things will improve. I haven't fully investigated it yet but I'm hoping we can rip out all of our custom server stuff and replace it with middleware now.
This is cool. I've been looking for something like this to pair with my nix env. Docker makes process management and logging in the dev environment so easy, but between the performance issues and abstraction leaks when jumping back and forth between native containers on linux and virtual machines on macos we gave up and started using nix to handle the reproducibility of our dev environment. The only thing I miss is the ease of process/service/log management. If anyone has any other solutions I would love to hear them.
If you want to experience a pepper rush with minimal topical pain and maximum enjoyment, buy/grow some fresh Carolina reapers and let them soak in a bottle of vodka or tequila for a couple of days. You can actually taste the pepper beyond the heat and still get a nice endorphin rush when you take a shot of it. It's also great for spicy margaritas
On Linux absolutely, the IO latency on MacOS with mounted volumes is atrocious. Using a nix environment also avoids the weird edge cases I tend to run into with volumes mounts and file ownership and such.
Fairly moderating a single massive global community is an unsolvable problem for both scale and cultural reasons. The current dominate model for social media will not work in the long run. Breaking down the task into sub-communities that are given moderator power helps with both the scale and cultural problems. Reddit however seems to be moving away from this model by deemphasizing the autonomy and identity of individual communities for a broader, singular reddit community.
After looking at it some more 'first-class' is overselling it. I'm still working my way through the code but I believe pretty much all interaction with bluesky/atproto by a user would be via federated instances like mastodon that can moderate as they see fit. The instances have final say in what you are allowed to do. The difference being you have a public key identity that is decoupled from a single instance. @moojd.blsky.app and @moojd.example.com can both be aliases to the same pubkey identity and if blsky.app is down my content will still sync with example.com.
Moderation is a first class citizen in this protocol and I imagine the official blue sky instance will be moderated just like any other big social media site. I'm still getting a feel for it but my first impression is that atproto is kinda like secure scuttlebutt with a federation layer and dns for memorable usernames.
1. Profile sync is client-side encrypted and doesn't require an account with anyone
2. Built in support for tor, ipfs, and webtorrent
3. Built in support for blocking social media embeds and tracking
4. Easier access to useful settings that would usually be buried in chrome
flags (disable drm, always show full url, etc..)
5. Mobile app has a way better UI for tabs
6. Built in ad, script, content, cookie, and fingerprint blocking
From your comments throughout this thread it seems as though you are either confident that your personal convictions will remain within the overton window in perpetuity or you lack the ability to imagine that one day they may not. Not to mention some of your convictions may have been outside the overton window in recent history. In a world where cash can be refused by businesses and governments can ban physical interaction, the ability to conduct digital commerce (and speech) must not be frustrated regardless of its general unsavoriness. The fact that we as a society have allowed a small cabal of payment processors to collude on who is allowed to conduct online commerce is a tragedy.
Absolutely. I just want to echo this for anyone in this thread considering using rush. Straying from the way rush wants to do things will bring pain. It is definitely not a good fit for every project but embracing it has solved a ton of problems for us (having tons of duplicated node_modules directories bringing intellij to it's knees, keeping versions in sync, path resolution, publishing, deployment)
If you're willing to go whole hog into pnpm, rush.js is really nice. You get a single unified node_modules and lock file for your entire repo with individual node_modules for each app/package projected with symlinks and local packages automatically symlinked together. We also have it set up so that when we push to our develop branch it builds, tests and bumps a prerelease version for only changed packages and dependents.
I am optimistic though. We are still in the early days of server-side javascript. It took 20 years for the greater php community to coalesce around a handful of quality libraries, frameworks, and solutions to things like user management instead of everyone rolling their own or using things like '$_GET["pass"] == "foo"' they they grabbed from a google search. Node is barely over a decade old. We are already seeing patterns mature in the node ecosystem and I hope things keep progressing that way.
This is a nice overview of modern front-end development but I'm constantly disappointed with what 'web framework' means in node-land. None of these things are strictly necessary when building a web app but authz/authn, user management, databases, server-side logic vs client-side logic, are pretty much always needed. When I see the phrase 'web framework' these are the things I am interested in seeing and they all seem to be treated as afterthoughts in the node community. Most tutorials either point you to paid/proprietary services or to really bad local solutions like back in the hotscripts days of php. If you google 'node user login' the first tutorial has you storing a password in plain text and checking the password with the equivalent of '=='. The first result when googling the same for php, python, and ruby all returned solutions using a hash.
I stand by the opinion that allowing multiple dependency versions was a major mistake that lead to both ballooning node_modules and abandoned packages getting caught up in your dependency tree just waiting for a malicious actor to hijack them.
In pip or composer, those dependencies have to be forked or removed or they will create conflicts.