Hacker Newsnew | past | comments | ask | show | jobs | submit | ekosz's commentslogin

Reading articles like this one, I do think people are trying to put a square peg (their applications) through a round hole (ATProto). The ATProto was designed around all data being public. You write public data to a user's PDS and then any application can read that public data and do something with it. If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals.

Imagine someone starts startup A on-top of the ATProto. They raise some money, get some users, some people love it, but ultimately they die. If the data was private to that service, that data dies with the startup. But if the data is all public future startup B can read that old data and do something with it. As a user that's brings me a ton of utility and comfort trying out new services.

If you're trying to built a local-first, mostly private service I just don't think the ATProto is the right tool for the job.


> If you're trying to built a local-first, mostly private service I just don't think the ATProto is the right tool for the job.

I agree! I think the "permissioned data" working group is aiming to solve the middle ground – where you want to broadcast something "publicly" but to a specific audience instead of the whole world (e.g. invite-only event, membership club). It's "private" in the sense it's not open to all but not in the sense that only you can see the data.

Nick Gerakines has been sharing some good examples of what you could build using permissioned data:

- Private Events: https://ngerakines.leaflet.pub/3mqxalpvn4k2e

- Bookmarks: https://ngerakines.leaflet.pub/3mqu653us3k2p

- Community content: https://ngerakines.leaflet.pub/3mqzsstcsok25

- Forums: https://ngerakines.leaflet.pub/3mr3uqjjaxs2d

- Polls: https://ngerakines.leaflet.pub/3mr3waxevjc24


atproto permissioned data [1] will solve the dilemma you're describing. Ultimately all the data is in the same place (your PDS) and you can always read and write any data there. If startup A goes away, startup B can read that old data and do something useful with it.

[1] https://github.com/bluesky-social/proposals/blob/main/0016-p...


> If all data was private (encrypted?) by default then that would defeat half of all of ATProto's goals.

Yeah, this is the reason why I don't understand why they succumbed to the idea ATProto must handle private and has started on work trying to figure it out (https://atproto.wiki/en/working-groups/private-data). Instead, focus on just really great public data archiving and displaying, at scale.


> I don't understand why they succumbed to the idea ATProto must handle private

The answer is very simple, the people demand it.

Technically, or if you squint the right way, it is a new protocol (atp://) that shares some parts with the public side. Notably the relay is out (for now?) and the data lives in a different sqlite table (iirc/aiui).


Yeah, running a social website where you can't write anything in private to just your friends is not very based.

Like this one?

Are you saying you are here to make friends on this thing?

HN is an exception to this rule imo, and remains our diamond in the rough

If the primary user concern is "all data is public", then the utility of ATProto is extremely narrow and will likely lose to something with a different philosophy.

That is about to change very, very soon though: https://dholms.leaflet.pub

Or you just use a different protocol for private stuff. Square peg, square hole. Round peg, round hole.

> The ATProto was designed around all data being public.

I might turn this around to say that ATProto was the square peg trying to fit into the round hole (the vast majority of people want privacy)


The main need is strong authentication, certainly for enabling P2P microblogging type apps.

The privacy stuff is covered by Signal etc. anyway, and you could layer that on top if you wanted to, but in a P2P setup privacy is always going to be a bit disappointing as so much metadata is inevitably exposed unless you do crazy stuff like flood fill the network with every message without regard to routing.


The definition of privacy is a spectrum, with what you describe at the most information secops end. Most people are not so worried about metadata leakage (they don't even know what it is, similar to atproto for most bluesky users).

What most want is to not be reposted and ratio'd by terminally online people like Blue MAGA did on Bluesky. They also just want to post to their followers or friends, not the world.


So in your concept if you are A and have two folowers B and C that don't know each other but both comment on your post what should happen? Should you see both but they not see each other?

This is the tip of the iceberg of boring questions that fall out, all of which have annoying user experience implications which are intimately tied to the underlying infrastructure and cryptosystems, effectively setting them in stone. There are reasons these systems fall into the camps of either federated with strong ID or really very centralized.


> what should happen?

A core principle of ATProto is that the cost of switching is low, thereby facilitating real competition on social media. So the answer is two parts

1. App views decide permission parameters for their modality and frame the user experience

2. Users use these permission parameters to dial in their personal or community experience

I believe there is more middle ground than you leave space for. See systems like ReBAC/Zanzibar, Anonymous Credentials, and UCANN. Google Workspace is a good model that many many people understand and are happy with (IAM wise).

With a design like this, you can build an enforceable world-read, mutual-following-write version of Bluesky, something users ask for every time Bluesky announces any new feature.


> 1. App views decide permission parameters for their modality and frame the user experience

Yeah, so this is the problem. A system flexible enough for that will be some combination of centralized, hilariously over complicated, massively inefficient, and full of odd unexpected behaviors.


Perhaps if you are after public square social media. If you are after small social media, the usage patterns and tradeoffs look different.

Modded Minecraft (smp) servers are interesting prior art for me.


the first version of bluesky was an internal effort to make twitter decentralized. atproto comes from twitter/ig type social media where almost all content is public so not supporting private data for v1 was an obvious choice.

they only decided to expand into other domains after the elon takeover made people move away from twitter and bluesky got popular way faster than expected.


> obvious choice ... decided to expand into other domains after

I'm not sure what the obvious answer is. I imagine the user insights at Twitter would be very informative, but was never on the inside to know. It's also worth noting that many members of the team joined on after ATProto was broken out from Twitter. Only they can provide an accurate recount of the information they had at hand and the decision making process around it.


I think Hyperscript is easy to bash on due to it's _very_ different syntax than what programmers are normally used to. That said, I think it's a really nice way to add little pieces of functionality without needing to bring out the JS frameworks.

It should be remembered that Hyperscript is meant to be paired with a technology like HTMX. I don't think the creator of Hyperscript would be suggesting to anyone that someone attempt to create a web application out of pure Hyperscript.


I think that's a large thing to assume. That announcement could also have been easily just damage control before the markets opened on Monday and nothing has yet to be truly hashed out and agreed on.


Because if they wanted to keep their compute credits that they desperately need to achieve their mission, they cannot be randomly pissing off their biggest collaborators. Just because the board doesn't legally _need_ to work with their for-profit investors, doesn't mean they shouldn't.

Had they played this like adults they could have seen through a smooth transition and not be looking at a total collapse like they are now.


I think what people in this thread and others are trying to say is that to run a organization like OpenAI you need lots and lots funding. AI research is incredibly costly due to highly paid researchers and an ungodly amount of GPU resources. To put all current funding at risk by pissing off current investors and enterprise customers puts the whole mission of the organization at risk. That's where the perceived incompetence comes from no mater how good the intentions are.


I understand that. What is missing is the purpose of running such an organisation. OpenAI has achieved a lot, but is it going to the direction and towards the purpose it was founded on? I do not see how one can argue that. For a non-profit, creating value is a means to a goal, not a goal in itself (as opposed to a for-profit org). People thinking that the problem of this move is that it destroys value for openAI showcase the real issue perfectly.


Exactly. Add to that the personal smearing of one person and it seems like a very unnecessarily negative maneuver.


Interesting to see oh this will affect (or not) the Rescript project.


Melange and ReScript target different audiences.

AFAIU, ReScript is a new language that offers an alternative to TypeScript.

Melange approaches the problem from the perspective of compatibility with OCaml / ReasonML. We've focused very hard on vertical integration with the OCaml Platform[1] and we're getting all the benefits with this release!

That said, both communities are fairly small, and I don't doubt that somewhat competing projects have some impact on community. From our perspective (the Melange team), our goals fit a specific use case, and e.g. Ahrefs, one of the leading SEO engines in the world, is using Melange[2] in production to power all their web experiences.

[1]: https://ocaml.org/docs/platform [2]: https://tech.ahrefs.com/ahrefs-is-now-built-with-melange-b14...


Great work on this write-up! Super informative and well written. It's refreshing to read posts like this


I'm using both, with with Rescript primarily on the front-end and Melange on the backed... both targeting JS/NodeJS.


We've been hearing complaints from AT&T users for months now that our website (https://vstream.com) doesn't work for them. I've tried hunting down the reasons & tried getting in touch with AT&T to no avail. This seems like it could be the very thing that's causing the issues for our users.

Now I just need to figure out what to tell our users that are having these issues...


I believe I can confirm that vstream.com is affected by this. It fails to fully load in a reasonable amount of time unless I connect via VPN, Verizon, or my (phone) hotspot.

Update: For what it's worth, the "above the fold" portion of the content loads down to "All Debuts". After that, there's a long blank space with a Loading indicator near the bottom. Eventually it loaded. I didn't keep track of how long, but it was almost certainly longer than 1 minute.


This appears to load fine for me on both AT&T fiber and AT&T cellular. It looks like all content on that site is being loaded from Cloudflare, so I'm curious if those users would be having issues with other Cloudflare protected sites as well?


You can try it yourself without any of the math with just a little bit of programming.

  function calc30(odds) {
    for (let i = 0; i < 30; i++) {
      if (Math.random() < odds) return true;
    }
    return false;
  }
  Array.from(Array(10000)).map(() => calc30(0.04)).filter(Boolean).length //=> 7022 or ~70%
  Array.from(Array(10000)).map(() => calc30(0.02)).filter(Boolean).length //=> 4545 or ~45%


Lattice | San Francisco, CA | Tech Lead, Software Engineer | Full Time | On-site

Lattice offers a performance management solution that helps companies put employees first. We offer 360 reviews, real-time feedback, weekly check-ins, and goal setting in a way that allows companies to focus on employee development, growth, and engagement. We launched in summer 2016 and have grown to over 800 customers around the world. Lattice has raised $9.8 million in total funding from Thrive Capital, Khosla Ventures, Y Combinator, Slack Fund, Marc Benioff, and others.

We are looking for product focused, full stack engineers to join our growing team. Our current stack is primarily React / Relay on the front-end and GraphQL / Node on the backend. You should be comfortable with both shipping products in JavaScript, and knowing when it’s not the right tool for the job.

Check our postings @ https://jobs.lever.co/latticehq/?team=Product


Lattice | Product Engineer (Fullstack or Frontend) | San Francisco | ONSITE, https://latticehq.com

Lattice is a performance management startup that helps companies track and improve employee performance. We believe that good performance management is critical for companies and employees to be successful. Unfortunately, the process is often painful, but we don't think it has to be that way.

We're growing really fast, based in San Francisco, and backed by some of the best investors including Thrive Capital, YC, Khosla, Marc Benioff, and Alexis Ohanian. The company was founded by myself (Eric Koslow) and our CEO Jack Altman. The engineering team only has four full time employees, so there's a tremendous opportunity to grow your career and have a big impact on a growing startup.

We use React on the frontend, NodeJS on the backend, and communicate over a GraphQL API. If you enjoying working with cutting edge technologies this is the place. We're looking for individuals that are product minded and enjoying owning problems from ideation to deployment. We have a very collaborative work environment and engineers work on all parts of the stack and across many domains.

If you're interested in the role, apply here: https://jobs.lever.co/latticehq/a29cefce-04ca-4a4e-86ba-9245...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: