Links:

For a lot of us, atproto projects are some of the biggest (most users, most publicized, most code written, etc.) projects we’ve ever done. For me, it’s also my first time working in open source (ironically, someone asked me to be more open about that)

If you can help, pls check out open issues.

I know not everyone thinks highly of atproto around these parts, but please don’t let that get in the way of welcoming a fellow rustacean into the open source world 🦀

  • BB_C@programming.dev
    link
    fedilink
    arrow-up
    7
    ·
    2 months ago

    Some shallow observations without really getting into the code:

    misc

    • Was hosting labeler/ResNet50_nsfw_model.pth in the repository really necessary?
      (I like my --filter=tree:0 clones to be maximally fast and small.)
    • Why not declare all dependencies in the workspace?
    • How old is the code (for real)?

    rsky-crypto

    • anyhow in library code.
    • Not liking that multibase dependency much either. I know that base64 at least got re-written since that crate’s last update (Nov 6, 2020).

    rsky-feedgen

    • serde_cbor is long dead (I was a user myself).
    • I’m not even sure why serde_cbor and serde_ipld_dagcbor are dependencies anyway.
    • We moved from lazy_static to once_cell a long time ago. And your use is available in std on stable Rust today.

    rsky-firehose

    • Here, all three CBOR dependencies are actually used.
    • CBOR (the format) used in $CURRENT_YEAR is meh anyway. But I guess that comes from IPLD.

    rsky-identity

    • anyhow in library code.

    rsky-pds

    • That’s quite the dependency list! Too long for me to take a closer look.
    • How many *base* dependencies does one need? All of them of course!

    rsky-syntax

    lazy_static and anyhow again.


    That’s all from a code organization and ecosystem PoV. Otherwise, things look normal and not fancy (which is good).

    Unfortunately, I don’t have the time to look beyond that at this moment.

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    2 months ago

    Sharing for anyone else not familiar with AT Protocol:

    The AT Protocol is an open, decentralized network for building social applications.

    FAQ Why not use ActivityPub?:

    Account portability and Scalability through activity aggregation

    Bluesky uses AT Protocol. The connected network/platform is called the Atmosphere.

    Bluesky Social has pledged to transfer the protocol’s development to a standards body. - Wikipedia

    I didn’t see any mention of other software/platforms using AT protocol on the protocol website or Wikipedia.

    • BB_C@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      Yeah. I read the linked explanation by OP.

      User repositories is basically how FMS on Freenet (now Hyphanet) works. The big difference is that JSON is used at AT instead of XML 😁. Also, things on Freenet are “content addressable” (what a buzz word) and immutable, always has been.

      General data scalability is a part of the Freenet network model. App bandwidth and sync is admittedly not optimal, since on FMS, you basically pull from everyone’s feed to your database (bar the ones you distrust, or others you trust their distrust judgment distrust). But that can be trivially fixed by adding watchers split over the keyspace. These watchers can give users metadata about who to pull/update from. This of course was never actually needed since the user-base is small.

      So reading about AT, I was left wondering. Is this really innovative? Then I read this part

      Our founding engineers were core IPFS and Dat engineers

      … and everything made sense. The masters of pretending they are coming up with new stuff are at it again.

    • taladar@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      The connected network/platform is called the Atmosphere.

      Not sure that is a good name from a search or brand recognition perspective.