6 ms·

Having done a decent bit of hacking around ActivityPub, when I read the (thin, which 'pfraze and others have copped to) documentation I immediately went "oh, th

Having done a decent bit of hacking around ActivityPub, when I read the (thin, which 'pfraze and others have copped to) documentation I immediately went "oh, this is going to be way more scalable than ActivityPub once it's done." It's not all roses. I'm not sold on lexicons and xrpc, but that's probably because I am up to my eyeballs in JSON Schema and OpenAPI on a daily basis and my experience and my existing toolkit probably biases me. I think starting with generally-accepted tooling probably would've been a better idea--but, in a vacuum, they're reasonably thought-out, they do address real problems, and I can't shake the feeling that the fine article is spitting mad for the sake of being spitting mad. While federation isn't there yet, granted, the idea that you can't write code against this is hogwash. There's a crazily thriving ecosystem already from the word jump, ~1K folks in the development Discord and a bunch of tooling being added on top of the platform by independent developers right now. Calm down. Nobody's taking ActivityPub away from people who like elephants.

rainonmoon 3y ago
> "oh, this is going to be way more scalable than ActivityPub once it's done." Can you elaborate on this?
- luckystarr 3y ago
  I think this is referring to the content-hashed user posts. Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc. This opens up the structure of the network, basically decentralizing it even _more_. Correct me if I'm wrong on this though.
  - vidarh 3y ago
    ActivityStreams just requires an object to have a unique URI. ActivityPub says it "should" be a https URI. However, since this URI is expected to be both unique and unchanging (if you put up the same content with a different id, it's a different object), you can choose to use it as the input to a hash function and put the posts in a content-addressable store. Mastodon will already check the local server first if you paste the URL of a post from another server in the Mastodon search bar, so it's already sort-of doing this, but only with the local server. So you can already do that with ActivityPub. If it becomes a need, people will consider it. There's already been more than one discussion about variations over this. (EDIT: More so than an improvement on scaling this would be helpful in ensuring there's a mechanism for posts to still be reachable by looking up their original URI after a user moves off a - possibly closing - server, though) The Fediverse also uses signatures, though they're not always passed on - fixing that (ensuring the JSON-LD signature is always carried with the post) would be nice.
    - aboodman 3y ago
      one important difference is: > expected Because the URI is only _expected_ to be immutable, not required, servers consuming these objects need to consider the case where the expectation is broken. For example, imagine the serving host has a bug and returns the wrong content for a URI. At scale this is guaranteed to happen. Because it can happen, downstream servers need to consider this case and build infrastructure to periodically revalidate content. This then propagates into the entire system. For example, any caching layer also needs to be aware that the content isn't actually immutable. With content hashes such a thing is just impossible. The data self-validates. If the hash matches, the data is valid, and it doesn't matter where you got it from. Data can be trivially propagated through the network.
      - vidarh 3y ago
        The URI is expected to be immutable. The URI can be used as a key. Whether the object is depends on the type of object. A hash over the content can not directly be used that way, but it can e.g be used to derive an original URI in a way that allows for predictable lookups without necessarily having access to the origin server. Posts are explicitly not immutable, so they do need to be revalidated, and that's fine. For a social network immutable content is a bad thing. People want to be able to edit, and delete, for all kinds of legitimate reasons, and while you can't protect yourself against people keeping copies you can at least make the defaults better.
        aboodman 3y ago
        > Posts are explicitly not immutable, so they do need to be revalidated, and that's fine. OK that's my point. In the AT protocol design the data backing posts is immutable. This makes sync, and especially caching a lot easier to make correct and robust because you never need to worry about revalidation at any level. > People want to be able to edit, and delete Immutable in this context just means the data blocks are immutable. You can still model logically mutable things, and implement edit/delete/whatever. Just like how Git does this.
        3y ago
  - goodpoint 3y ago
    > Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc Does that makes it more difficult to implement the right to be forgotten and block spam and trolls?
    - XorNot 3y ago
      Doesn't it make it easier? A list of hashes which should be blacklisted means servers obeying rulings are never at risk of returning that data (this would also work offensively: poll for forbidden hashes and see who responds).
      - goodpoint 3y ago
        ...and now you have to track which instance is authorize to block which hash, creating a lot of extra complexity. Plus, we need to trust all instances to really delete stuff. It makes life really easy for spammers.
        XorNot 3y ago
        [flagged]
        goodpoint 3y ago
        I explained the point twice.
        dang 3y ago
        Please edit out swipes from your HN comments, as the guidelines ask: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Your comment would be fine without that first bit.
vidarh 3y ago
If they'd proposed (or even just implemented) improvements that at least suggested they'd considered existing options and wanted to try to maximise the ability to do interop (even with proxies), I'd have been more sympathetic. But AT to mean seems to be a big ball of Not Invented Here that makes me worry that either they didn't care and try, or that they choice to make interop worse for a non-technical reason.
- detourdog 3y ago
  During this stage of discovery I'm completely comfortable with ground up rethinks. I don't feel we have the correct solution and there is no commercial reason to ge this thing shipped. Now is the time to explore all the possibilities. Once we have explored the problem space we should graft the best bits together for a final solution, if needed. I'm not sure I see the value of standardizing on a single protocol. Multiple protocols can access the same data store. Adopting one protocol doesn't preclude other protocols. I believe Developers should adopt all the protocols.
  - vidarh 3y ago
    Ground up rethinks that takes into account whether or not there's an actual reason to make a change is good. Ground up rethinks that throws things away for the sake of throwing them away even what they end up doing would layer cleanly are not. They're at best lazy. At worst intentional attempts at diluting effort. I'm hoping they've only been lazy.
    - detourdog 3y ago
      I'm not disagreeing. To say that there is only one way or to project presumed goals and intentions is too far for me. I firmly believe that protocols are developed through vigorous rewrites and aren't nearly as important as the data-stores they provide access to. I would like our data-stores to be stagnant and as required we develop protocols. Figuring out a method to deal with whatever the hosted data-store's chosen protocol is seems correct to me. I just don't see mutual exclusivity. Consider the power of supporting both protocols.

rainonmoon 3y ago

> "oh, this is going to be way more scalable than ActivityPub once it's done." Can you elaborate on this?

luckystarr 3y ago
I think this is referring to the content-hashed user posts. Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc. This opens up the structure of the network, basically decentralizing it even _more_. Correct me if I'm wrong on this though.
- vidarh 3y ago
  ActivityStreams just requires an object to have a unique URI. ActivityPub says it "should" be a https URI. However, since this URI is expected to be both unique and unchanging (if you put up the same content with a different id, it's a different object), you can choose to use it as the input to a hash function and put the posts in a content-addressable store. Mastodon will already check the local server first if you paste the URL of a post from another server in the Mastodon search bar, so it's already sort-of doing this, but only with the local server. So you can already do that with ActivityPub. If it becomes a need, people will consider it. There's already been more than one discussion about variations over this. (EDIT: More so than an improvement on scaling this would be helpful in ensuring there's a mechanism for posts to still be reachable by looking up their original URI after a user moves off a - possibly closing - server, though) The Fediverse also uses signatures, though they're not always passed on - fixing that (ensuring the JSON-LD signature is always carried with the post) would be nice.
  - aboodman 3y ago
    one important difference is: > expected Because the URI is only _expected_ to be immutable, not required, servers consuming these objects need to consider the case where the expectation is broken. For example, imagine the serving host has a bug and returns the wrong content for a URI. At scale this is guaranteed to happen. Because it can happen, downstream servers need to consider this case and build infrastructure to periodically revalidate content. This then propagates into the entire system. For example, any caching layer also needs to be aware that the content isn't actually immutable. With content hashes such a thing is just impossible. The data self-validates. If the hash matches, the data is valid, and it doesn't matter where you got it from. Data can be trivially propagated through the network.
    - vidarh 3y ago
      The URI is expected to be immutable. The URI can be used as a key. Whether the object is depends on the type of object. A hash over the content can not directly be used that way, but it can e.g be used to derive an original URI in a way that allows for predictable lookups without necessarily having access to the origin server. Posts are explicitly not immutable, so they do need to be revalidated, and that's fine. For a social network immutable content is a bad thing. People want to be able to edit, and delete, for all kinds of legitimate reasons, and while you can't protect yourself against people keeping copies you can at least make the defaults better.
      - aboodman 3y ago
        > Posts are explicitly not immutable, so they do need to be revalidated, and that's fine. OK that's my point. In the AT protocol design the data backing posts is immutable. This makes sync, and especially caching a lot easier to make correct and robust because you never need to worry about revalidation at any level. > People want to be able to edit, and delete Immutable in this context just means the data blocks are immutable. You can still model logically mutable things, and implement edit/delete/whatever. Just like how Git does this.
        3y ago
- goodpoint 3y ago
  > Using this model one can pull content from _anywhere_ without having to worry about MITM forgeries etc Does that makes it more difficult to implement the right to be forgotten and block spam and trolls?
  - XorNot 3y ago
    Doesn't it make it easier? A list of hashes which should be blacklisted means servers obeying rulings are never at risk of returning that data (this would also work offensively: poll for forbidden hashes and see who responds).
    - goodpoint 3y ago
      ...and now you have to track which instance is authorize to block which hash, creating a lot of extra complexity. Plus, we need to trust all instances to really delete stuff. It makes life really easy for spammers.
      - XorNot 3y ago
        [flagged]
        goodpoint 3y ago
        I explained the point twice.
        dang 3y ago
        Please edit out swipes from your HN comments, as the guidelines ask: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Your comment would be fine without that first bit.

vidarh 3y ago

If they'd proposed (or even just implemented) improvements that at least suggested they'd considered existing options and wanted to try to maximise the ability to do interop (even with proxies), I'd have been more sympathetic. But AT to mean seems to be a big ball of Not Invented Here that makes me worry that either they didn't care and try, or that they choice to make interop worse for a non-technical reason.

detourdog 3y ago
During this stage of discovery I'm completely comfortable with ground up rethinks. I don't feel we have the correct solution and there is no commercial reason to ge this thing shipped. Now is the time to explore all the possibilities. Once we have explored the problem space we should graft the best bits together for a final solution, if needed. I'm not sure I see the value of standardizing on a single protocol. Multiple protocols can access the same data store. Adopting one protocol doesn't preclude other protocols. I believe Developers should adopt all the protocols.
- vidarh 3y ago
  Ground up rethinks that takes into account whether or not there's an actual reason to make a change is good. Ground up rethinks that throws things away for the sake of throwing them away even what they end up doing would layer cleanly are not. They're at best lazy. At worst intentional attempts at diluting effort. I'm hoping they've only been lazy.
  - detourdog 3y ago
    I'm not disagreeing. To say that there is only one way or to project presumed goals and intentions is too far for me. I firmly believe that protocols are developed through vigorous rewrites and aren't nearly as important as the data-stores they provide access to. I would like our data-stores to be stagnant and as required we develop protocols. Figuring out a method to deal with whatever the hosted data-store's chosen protocol is seems correct to me. I just don't see mutual exclusivity. Consider the power of supporting both protocols.