7 ms·

Reading this I hear someone passionate about technology for the sake of technology. Which is cool, I totally get the desire to build things oneself, but it does

Reading this I hear someone passionate about technology for the sake of technology. Which is cool, I totally get the desire to build things oneself, but it doesn't really address the substantive questions people are asking about AT: An open protocol exists that broadly does what you want to do. That protocol is stable and widely used. That in itself, regardless of the quality of the protocol, already represents an OKish argument to strongly consider using it. If you're going to go NIH your replacement needs to not just be better but substantially better, and you should also show understanding of the original open spec. Sofar, Bluesky's already been caught redoing little things in ways that show a lack of reading/understanding of open specs (.well-known domain verification), and the proposed technological improvements over ActivityPub fall into three categories: 1. Something ActivityPub already supports as a "SHOULD" or a "MAY": there's arguments to be made these would be better as "MUST", but either way there's no reason AT couldn't've just implemented ActivityPub with these added features. 2. Highly debatable improvements - as highlighted by this article. I do think some of this article is hyperbole but it certainly highlights that some of the proposed benefits are not clear cut. 3. Such a minor improvement as to be nowhere near worth the incompatibility. All that coupled with the continuous qualifiers of it being incomplete/beta/WIP when there's a mature alternative really just doesn't present well.

zaphar 3y ago
I run a single user ActivityPub instance with a minimal following and small number of people across multiple instances that I follow. From a user perspective ActivityPub is fine I have no complaints. However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already. From a single individual user this won't necessarily be obvious right off the bat. But it will tend to manifest in either overworked operations people or slow janky instance performance. While it's certainly a reasonable question whether the world needs another federated social protocol or not ATProto definitely solves real problems with the ActivityPub protocol.
- lucideer 3y ago
  > ActivityPub is incredibly chatty. > ATProto is a better looking protocol already. Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly? > If this had to scale to a larger instance the costs would spiral fast. Are we talking bandwidth costs or processing. I know the popular ActivityPub implementation is widely considered to be pretty inefficient processing-wise for reasons unrelated to the protocol itself: is that a factor here?
  - mkr-hn 3y ago
    Sidekiq seems to be the culprit from what I've seen and read from people who've run into this issue. It gets overloaded fast if you don't have enough processing power in front of the queue. Lighter implementations apparently do something different, or are more efficient in handling their queues without whatever overhead Sidekiq adds.
  - zaphar 3y ago
    One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new messages to every single one of the people following them. This means that if 10 users are following me from the same server I will not have 1 push for that instance, I'll gave 10 pushes for the same single unchanged message. This is built into the protocol. That's a lot of throughput for something that could be much much less chatty. Now on my single instance it's not too bad because 1. I follow maybe 40 people and 2. I have like max 10 followers. For an instance with people with high follower counts across multiple other instances it could get to be a problem fast. Edit: my previous description used fetch when it should have used push.
    - Spivak 3y ago
      Isn't that "more than once instance" rather than "more than one user"? I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.
vidarh 3y ago
This is a great summary of what my concerns are as well. I'd maybe add one more point: * Improvements that'd layer cleanly on top of ActivityPub if they'd made any attempt at all. E.g. being able to "cheaply" ensure that you have a current view of all a given users objects is not covered in ActivityPub - you're expected to basically want to get the current state of one specific object, because most of the time that is what you'll want. So maybe it falls in the "highly debatable" category, but we also have a trivial existing solution from another open spec: RemoteStorage mandates etag's where a parent "directory" object's etag will change if a contained object changes, and embeds that in a JSON-LD collection as the directory listings. If you feel strongly that this is needed to be able to rapidly sync changes to a large collection, an ActivityPub implementation can just support that mechanism without any spec changes being needed at all (but documenting it in case other implementations wants to do so would be nice). Heck, you can "just" add minimal RemoteStorage compatibility to your ActivityPub implementation, since that too users Webfinger, and exposing your posts as objects in a RemoteStorage share would be easy enough. Want to do a purely "pull" based ActivityPub version the way AT is "pull"? Support the above (w/fallback of assuming every object may have changed if you care about interop), make your "inbox" endpoints do nothing and tell people you've added an attribute to the actor objects to indicate you prefer to pull and so to not push to you. Upside is, if any of the AT functionality turns out to be worthwhile, it'll be trivial to "steal" the good bits without dropping interop. (Also, I wanted to see exactly how AT did pulls, and looked at the AT Proto spec, and now I fully concur with the title of this article)
- lucideer 3y ago
  Your added point fits in with the initial red flag for me - before I saw pfraze's (excellent) post here - that the vast majority of what I've read advocating for ATProto says very clearly: "Account portability is the major reason why we chose to build a separate protocol.". Account portability is in no way incompatible with ActivityPub. It's not built into the spec., but it's also not forbidden / prevented by the spec. in any way. From ActivityPub's perspective it's an implementation detail. Would it be nice if it was built into the spec: yes. Does that justify throwing out the baby with the bathwater? I was hoping pfraze would offer some better reasoning, but while the post above is a great read for the technically curious, its very "in the weeds" so doesn't really address the important high-level questions. Textbook "technologists just want to technologise" vibes: engineers love reinventing things because working out problems for yourself is the fun part, even if many people have come together to collaborate on solving those problems before.
moojd 3y ago
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.
- lucideer 3y ago
  Bluesky is a Twitter-like platform like Mastodon, so the comparison makes sense if you look at the primary implementations. SSB is also decentralised, while ATProto is federated - like ActivityPub.
  - Ferkv 3y ago
    User Identity in ATProto is decentralized, it's meant to use W3C DIDs. That's actually one of the things that bugs me about ActivityPub... unless I'm running my own one-single-user instance I won't have control over my own identity. It's also very weird how even on a supposedly "federated" system the only way to ensure you can access content from all instances (even if they differ in philosophy or are on opposite sides of some "inter-instance-war") is to have separate accounts for each side... it kind of defeats the point of federation. There's even places like lemmy which instead of using blocklists use allowlists, so they will only federate with pre-approved instances.
    - lucideer 3y ago
      > User Identity in ATProto is decentralized It is but that's largely conceptual so doesn't really mean anything in the context of the protocol. These are message exchange protocols so the defining element is whether the messaging is federated or decentralised. Fwiw AP also supports DID I just haven't seen any implementations use it, since it strongly recommends other ID (a mistake imo). > It's also very weird how... What you're describing here is a cultural phenomenon, not a technological one, so isn't really relevant to the discussion: ActivityPub siloing isn't a feature of the protocol, it's an emergent feature of the ecosystem/communities. It's also worth mentioning it isn't usually implemented as you describe, unless you're specifically concerned with maximising your own reach from a publishing perspective: most instances allow individual users to follow individual users on another "blocked" instance - its usually just promotion/sharing & discovery that are restricted.
zoogeny 3y ago
> If you're going to go NIH your replacement needs to not just be better but substantially better, and you should also show understanding of the original open spec. I just disagree with this in principle. I wonder what the tech equivalent of "laissez faire" would be. To this day I don't understand how anyone in the tech world thinks they can make a single demand of anyone else. Even as a customer I believe you can really only demand that the people you are paying deliver what is contractually and legally required. But outside of that ... I just don't understand people's mentality on this subject. What is it about this specific area of the web that attracts these idealogical zealots? I had the same head-scratching moment in the early 2000s when RSS and Atom were duking it out.
- lucideer 3y ago
  > I don't understand how anyone in the tech world thinks they can make a single demand of anyone else. Ultimately, yes you're right, no-one can make actual "demands" of anyone else. My language above is demanding, certainly, but ultimately I'm just arguing opinion. I cannot control any outcomes of what Bluesky or any other enterprise choose to pursue. > What is it about this specific area of the web that attracts these idealogical zealots? I think it stems from the unprecedented success of such zealots in the 1980s, which have differentiated the technological landscape of software technologies from previous areas of engineering by making them more approachable, accessible, interoperable and ultimately democratised. That's largely been the result of people arguing passionately on the internet to advocate for that level of openness, collab & interop.
  - zoogeny 3y ago
    > I think it stems from the unprecedented success of such zealots in the 1980s, I would challenge this belief, that the success of Linux, or the Web technologies (TCP, HTTP, HTML, etc.) were primarily the result of the zealots from the 80s. I would challenge the belief that protocols for Twitter-like communication fall into the same category as things like POSIX, TCP/IP, HTTP, HTML, etc. > That's largely been the result of people arguing passionately on the internet to advocate for that level of openness, collab & interop. My own opinion is the key to success was a large number of people writing useful code and an even larger number of people using that code. One example that comes to mind is how HTML was spun out from w3c into WhatWG. Controversial at the time to say the least but IMO necessary to get away from the bickering of semantic web folks who were grinding the progress to a halt. HTML 5 won the day over XHTML (actually to my disappointment). The reason wasn't the impassioned arguments of the semantic web zealots, it was the working implementations delivered by the WhatWG members to serve the literal millions of people using their applications. Another example is the success of Linux over Hurd - the latter being a technology initially supported by the most vocal and ideological of all the zealots. It is a simple fact that if AT garners sufficiently useful implementations and those implementations garner sufficient numbers of users - all of the impassioned arguments against it will have been for naught. So those arguing should probably stop so that they can focus on implementing ActivityPub (or whatever they think is best) and attracting users. I guarantee you that if ActivityPub attracts millions of users then Bluesky will suddenly see the light. They will change course just like every big tech company did when Linux became successful. It is also why I think all of the hot-air on RSS and Atom was literally wasted. As technologies both have thus-far failed to attract enough users to make it worth it. I would bet that the same will be true of both AT and ActivityPub. Unless someone develops an application that uses one or the other and it manages to attract as many users as Twitter then people are just wasting time for nothing.
gojomo 3y ago
There's a growing base of users who have reached the epiphany (by multiple paths) that both identities & content-addressing MUST be cryptographically-rooted, or else users' privacy & communications will remain at the mercy of feudal centralizers with endless strong incentives to work against their interests. For such users, any offering without these is a non-starter, dead-on-arrival. People with resistance to this epiphany sound like those who used to insist, "HTTP is fine" (even when it put people at risk) or "MD5 is fine" (long after it was cryptographically broken). Most will get it eventually, either through painful tangible experiences or the gradual accumulation of social proof. A bolt-on/fix-up of an older protocol might work, if done with extreme competence & broad consensus. And, some in the ActivityPub world had the cryptoepiphany very early! Ideas for related upgrades have been kicked around for a long time. But progress has been negligible, & knee-jerk resistance strong, & the deployed-habits/technical-debts make it harder there than in a green-field project. Hence: a new generation of systems that bake the epiphany in at their core – which is, ultimately, a more robust approach than a bolt-on/fix-up. Because so many of those recently experiencing this cryptoepiphany reached it via experience with cryptotokens, many of these systems enthusiastically integrate other aspects of the cryptotoken world – which of course turns off many people, for a variety of good and bad reasons. But the link with cryptotokens is plausibly inessential, at least at the get-go. The essentials of grounding identity & addressing in cryptography predate Bitcoin by decades, and had communities-of-practice totally independent of the cryptoeconomics world. A relative advantage Bluesky may have is their embrace of cryptographic addressing behind-the-scenes, without pushing its details to those who might confuse it with promotional crypto-froth. Users will, if all goes well, just see the extra security, scalability, and user sovereignty against abuses that it offers. We'll see.
- account42 3y ago
  HTTP is fine for a lot of uses. So is MD5. Crytography and security in general are often cargo-culted without any consideration for the negative implications. > this cryptoepiphan Bro are you for real.
  - gojomo 3y ago
    It was clear that MD5 didn't meet the goals it was designed for in 1994, when experts recommended it be phased out for its originally intended uses. It's not fine here in 2023. If you need a secure hash, it's been proven broken for 10 years now. If you don't need a secure hash, others are far more performant. Using it, or worse, advocating for its use, is a way to signal your thinking is years behind the leading edge, and also best practices, and even justifiable practices. HTTP's simplicity could make it tolerable for some places where world-readability is a goal - but people, echoing your sentiments here, have said it was "fine" even in situations where it was putting people at risk. Major browser makers recognize the risk, and are now subtly discouraging HTTP, and this discouragement will grow more intense over time.
mvkel 3y ago
I ran into this trap very early in my entrepreneurial journey. Developed a data "standard" for events in a vacuum, convinced that nothing else in the world could possibly exist. Then spent a good year learning the lessons that already-existing standards had learned and adapted from years ago. A protocol like this doesn't work without community adoption. And the best way to get the community to adopt is to build on what's already there rather than trying to reinvent the fridge.

zaphar 3y ago

I run a single user ActivityPub instance with a minimal following and small number of people across multiple instances that I follow. From a user perspective ActivityPub is fine I have no complaints. However from an Ops perspective ActivityPub is incredibly chatty. If this had to scale to a larger instance the costs would spiral fast. Operationally and cost efficiency wise ATProto is a better looking protocol already. From a single individual user this won't necessarily be obvious right off the bat. But it will tend to manifest in either overworked operations people or slow janky instance performance. While it's certainly a reasonable question whether the world needs another federated social protocol or not ATProto definitely solves real problems with the ActivityPub protocol.

lucideer 3y ago
> ActivityPub is incredibly chatty. > ATProto is a better looking protocol already. Are there benchmarks for this? What's the level of difference here? Request frequency seems closely linked to activity and XRPC bodies are JSON just as ActivityPub so message size should be within order of magnitude at least. Are there architectural differences that reduce request frequency significantly? > If this had to scale to a larger instance the costs would spiral fast. Are we talking bandwidth costs or processing. I know the popular ActivityPub implementation is widely considered to be pretty inefficient processing-wise for reasons unrelated to the protocol itself: is that a factor here?
- mkr-hn 3y ago
  Sidekiq seems to be the culprit from what I've seen and read from people who've run into this issue. It gets overloaded fast if you don't have enough processing power in front of the queue. Lighter implementations apparently do something different, or are more efficient in handling their queues without whatever overhead Sidekiq adds.
- zaphar 3y ago
  One example of the chattiness is a flow where more than one person is following the same individual on another server. That person will have to push new messages to every single one of the people following them. This means that if 10 users are following me from the same server I will not have 1 push for that instance, I'll gave 10 pushes for the same single unchanged message. This is built into the protocol. That's a lot of throughput for something that could be much much less chatty. Now on my single instance it's not too bad because 1. I follow maybe 40 people and 2. I have like max 10 followers. For an instance with people with high follower counts across multiple other instances it could get to be a problem fast. Edit: my previous description used fetch when it should have used push.
  - Spivak 3y ago
    Isn't that "more than once instance" rather than "more than one user"? I think the weirdness is with Bluesky all that cost is still there but it's now handled by a small group of massive megacorps which is a real tangible benefit to self-hosters but you could have that on top of AP by running your service off what would essentially be a massive global cache of AP content which is what the indexer is.

vidarh 3y ago

This is a great summary of what my concerns are as well. I'd maybe add one more point: * Improvements that'd layer cleanly on top of ActivityPub if they'd made any attempt at all. E.g. being able to "cheaply" ensure that you have a current view of all a given users objects is not covered in ActivityPub - you're expected to basically want to get the current state of one specific object, because most of the time that is what you'll want. So maybe it falls in the "highly debatable" category, but we also have a trivial existing solution from another open spec: RemoteStorage mandates etag's where a parent "directory" object's etag will change if a contained object changes, and embeds that in a JSON-LD collection as the directory listings. If you feel strongly that this is needed to be able to rapidly sync changes to a large collection, an ActivityPub implementation can just support that mechanism without any spec changes being needed at all (but documenting it in case other implementations wants to do so would be nice). Heck, you can "just" add minimal RemoteStorage compatibility to your ActivityPub implementation, since that too users Webfinger, and exposing your posts as objects in a RemoteStorage share would be easy enough. Want to do a purely "pull" based ActivityPub version the way AT is "pull"? Support the above (w/fallback of assuming every object may have changed if you care about interop), make your "inbox" endpoints do nothing and tell people you've added an attribute to the actor objects to indicate you prefer to pull and so to not push to you. Upside is, if any of the AT functionality turns out to be worthwhile, it'll be trivial to "steal" the good bits without dropping interop. (Also, I wanted to see exactly how AT did pulls, and looked at the AT Proto spec, and now I fully concur with the title of this article)

lucideer 3y ago
Your added point fits in with the initial red flag for me - before I saw pfraze's (excellent) post here - that the vast majority of what I've read advocating for ATProto says very clearly: "Account portability is the major reason why we chose to build a separate protocol.". Account portability is in no way incompatible with ActivityPub. It's not built into the spec., but it's also not forbidden / prevented by the spec. in any way. From ActivityPub's perspective it's an implementation detail. Would it be nice if it was built into the spec: yes. Does that justify throwing out the baby with the bathwater? I was hoping pfraze would offer some better reasoning, but while the post above is a great read for the technically curious, its very "in the weeds" so doesn't really address the important high-level questions. Textbook "technologists just want to technologise" vibes: engineers love reinventing things because working out problems for yourself is the fun part, even if many people have come together to collaborate on solving those problems before.

moojd 3y ago

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.

lucideer 3y ago
Bluesky is a Twitter-like platform like Mastodon, so the comparison makes sense if you look at the primary implementations. SSB is also decentralised, while ATProto is federated - like ActivityPub.
- Ferkv 3y ago
  User Identity in ATProto is decentralized, it's meant to use W3C DIDs. That's actually one of the things that bugs me about ActivityPub... unless I'm running my own one-single-user instance I won't have control over my own identity. It's also very weird how even on a supposedly "federated" system the only way to ensure you can access content from all instances (even if they differ in philosophy or are on opposite sides of some "inter-instance-war") is to have separate accounts for each side... it kind of defeats the point of federation. There's even places like lemmy which instead of using blocklists use allowlists, so they will only federate with pre-approved instances.
  - lucideer 3y ago
    > User Identity in ATProto is decentralized It is but that's largely conceptual so doesn't really mean anything in the context of the protocol. These are message exchange protocols so the defining element is whether the messaging is federated or decentralised. Fwiw AP also supports DID I just haven't seen any implementations use it, since it strongly recommends other ID (a mistake imo). > It's also very weird how... What you're describing here is a cultural phenomenon, not a technological one, so isn't really relevant to the discussion: ActivityPub siloing isn't a feature of the protocol, it's an emergent feature of the ecosystem/communities. It's also worth mentioning it isn't usually implemented as you describe, unless you're specifically concerned with maximising your own reach from a publishing perspective: most instances allow individual users to follow individual users on another "blocked" instance - its usually just promotion/sharing & discovery that are restricted.

zoogeny 3y ago

> If you're going to go NIH your replacement needs to not just be better but substantially better, and you should also show understanding of the original open spec. I just disagree with this in principle. I wonder what the tech equivalent of "laissez faire" would be. To this day I don't understand how anyone in the tech world thinks they can make a single demand of anyone else. Even as a customer I believe you can really only demand that the people you are paying deliver what is contractually and legally required. But outside of that ... I just don't understand people's mentality on this subject. What is it about this specific area of the web that attracts these idealogical zealots? I had the same head-scratching moment in the early 2000s when RSS and Atom were duking it out.

lucideer 3y ago
> I don't understand how anyone in the tech world thinks they can make a single demand of anyone else. Ultimately, yes you're right, no-one can make actual "demands" of anyone else. My language above is demanding, certainly, but ultimately I'm just arguing opinion. I cannot control any outcomes of what Bluesky or any other enterprise choose to pursue. > What is it about this specific area of the web that attracts these idealogical zealots? I think it stems from the unprecedented success of such zealots in the 1980s, which have differentiated the technological landscape of software technologies from previous areas of engineering by making them more approachable, accessible, interoperable and ultimately democratised. That's largely been the result of people arguing passionately on the internet to advocate for that level of openness, collab & interop.
- zoogeny 3y ago
  > I think it stems from the unprecedented success of such zealots in the 1980s, I would challenge this belief, that the success of Linux, or the Web technologies (TCP, HTTP, HTML, etc.) were primarily the result of the zealots from the 80s. I would challenge the belief that protocols for Twitter-like communication fall into the same category as things like POSIX, TCP/IP, HTTP, HTML, etc. > That's largely been the result of people arguing passionately on the internet to advocate for that level of openness, collab & interop. My own opinion is the key to success was a large number of people writing useful code and an even larger number of people using that code. One example that comes to mind is how HTML was spun out from w3c into WhatWG. Controversial at the time to say the least but IMO necessary to get away from the bickering of semantic web folks who were grinding the progress to a halt. HTML 5 won the day over XHTML (actually to my disappointment). The reason wasn't the impassioned arguments of the semantic web zealots, it was the working implementations delivered by the WhatWG members to serve the literal millions of people using their applications. Another example is the success of Linux over Hurd - the latter being a technology initially supported by the most vocal and ideological of all the zealots. It is a simple fact that if AT garners sufficiently useful implementations and those implementations garner sufficient numbers of users - all of the impassioned arguments against it will have been for naught. So those arguing should probably stop so that they can focus on implementing ActivityPub (or whatever they think is best) and attracting users. I guarantee you that if ActivityPub attracts millions of users then Bluesky will suddenly see the light. They will change course just like every big tech company did when Linux became successful. It is also why I think all of the hot-air on RSS and Atom was literally wasted. As technologies both have thus-far failed to attract enough users to make it worth it. I would bet that the same will be true of both AT and ActivityPub. Unless someone develops an application that uses one or the other and it manages to attract as many users as Twitter then people are just wasting time for nothing.

gojomo 3y ago

There's a growing base of users who have reached the epiphany (by multiple paths) that both identities & content-addressing MUST be cryptographically-rooted, or else users' privacy & communications will remain at the mercy of feudal centralizers with endless strong incentives to work against their interests. For such users, any offering without these is a non-starter, dead-on-arrival. People with resistance to this epiphany sound like those who used to insist, "HTTP is fine" (even when it put people at risk) or "MD5 is fine" (long after it was cryptographically broken). Most will get it eventually, either through painful tangible experiences or the gradual accumulation of social proof. A bolt-on/fix-up of an older protocol might work, if done with extreme competence & broad consensus. And, some in the ActivityPub world had the cryptoepiphany very early! Ideas for related upgrades have been kicked around for a long time. But progress has been negligible, & knee-jerk resistance strong, & the deployed-habits/technical-debts make it harder there than in a green-field project. Hence: a new generation of systems that bake the epiphany in at their core – which is, ultimately, a more robust approach than a bolt-on/fix-up. Because so many of those recently experiencing this cryptoepiphany reached it via experience with cryptotokens, many of these systems enthusiastically integrate other aspects of the cryptotoken world – which of course turns off many people, for a variety of good and bad reasons. But the link with cryptotokens is plausibly inessential, at least at the get-go. The essentials of grounding identity & addressing in cryptography predate Bitcoin by decades, and had communities-of-practice totally independent of the cryptoeconomics world. A relative advantage Bluesky may have is their embrace of cryptographic addressing behind-the-scenes, without pushing its details to those who might confuse it with promotional crypto-froth. Users will, if all goes well, just see the extra security, scalability, and user sovereignty against abuses that it offers. We'll see.

account42 3y ago
HTTP is fine for a lot of uses. So is MD5. Crytography and security in general are often cargo-culted without any consideration for the negative implications. > this cryptoepiphan Bro are you for real.
- gojomo 3y ago
  It was clear that MD5 didn't meet the goals it was designed for in 1994, when experts recommended it be phased out for its originally intended uses. It's not fine here in 2023. If you need a secure hash, it's been proven broken for 10 years now. If you don't need a secure hash, others are far more performant. Using it, or worse, advocating for its use, is a way to signal your thinking is years behind the leading edge, and also best practices, and even justifiable practices. HTTP's simplicity could make it tolerable for some places where world-readability is a goal - but people, echoing your sentiments here, have said it was "fine" even in situations where it was putting people at risk. Major browser makers recognize the risk, and are now subtly discouraging HTTP, and this discouragement will grow more intense over time.

mvkel 3y ago

I ran into this trap very early in my entrepreneurial journey. Developed a data "standard" for events in a vacuum, convinced that nothing else in the world could possibly exist. Then spent a good year learning the lessons that already-existing standards had learned and adapted from years ago. A protocol like this doesn't work without community adoption. And the best way to get the community to adopt is to build on what's already there rather than trying to reinvent the fridge.