Citiverse
  • hipsterelectron@circumstances.runH
    1
    0

    @kopper unfortunately not the point but this is easily the craziest css i've ever seen. bravo

  • amy@sk.girlthi.ngA
    1
    0

    @kopper@not-brain.d.on-t.work 1am rants are always peak writing

  • kopper@not-brain.d.on-t.workK
    15
    0
    @fiore activitypub client-to-server
  • fiore@brain.worm.pinkF
    1
    0

    @kopper@not-brain.d.on-t.work isnt that how AP usually works ? ( im stupid but interested )

  • kopper@not-brain.d.on-t.workK
    15
    0
    @fiore no not really. usually only the server-to-server bit is used and (microblogging) client apps use mastodon's bespoke api
  • kopper@not-brain.d.on-t.workK
    15
    0
    another minor update, fixing a few typos and linking a few more things. also toned down the snark cuz i've been enough of a dick already

    codeberg.org/KittyShopper/w.on-t.work/commit/d998852290e9652f4511108ea2b8729d5e148205
  • lina@tech.lgbtL
    1
    0

    @kopper not a complaint but i do find it interesting that like this we would have "instances" be similar to bsky PDS [probably with a lot of differences re: federation but] and the "clients" like their appview[-s] + whatever was the name for the feed curator/moderation thing

  • alexia@shrimp.starlightnet.workA
    1
    0
    @kopper haven't read the full thing but so far I very much like this
  • kopper@not-brain.d.on-t.workK
    15
    0
    @lina yeah it's effectively the same architecture, i did have an explicit mention of that but removed it as it was attached to some unnecessary snark
  • kopper@not-brain.d.on-t.workK
    15
    0
    i should open issues on github.com/swicg/activitypub-api/issues for all my proposals and end up committing 10 faux pas in a row because they still havent decided on if they want a monolithic One Server that replaces the mastodon api or something actually worthwhile to implement
  • volpeon@icy.wyvern.ripV
    1
    0

    @kopper Your opinions are pretty much the same as mine. That's always how I approached my own instance server projects before the requirements inevitably grew way over my head haha

  • kopper@not-brain.d.on-t.workK
    15
    0
    also unrelated but i may as well throw this in here since i keep thinking about it but. doing c2s this way also opens your client up to being multi-protocol. say you want to be like wafrn and federate both via ap and atproto, you can then plug in PDSs the same way you plugged in AP C2S servers. your own client can then merge both into one

    this does lose a handful of the benefits some features mentioned would bring. you would need to store all the data yourself as you'll need your own common API format, you'd need to maintain your own login tokens, your backend would need to act as a proxy for writing to the PDS/C2S server which enables you to cut that off completely if you "go evil". i did touch upon these downsides on
    w.on-t.work/this-tall-to-interoperate

    or alternatively, you could have a "personal bridgy" which can be both a c2s client and an atproto client/appview and bridge the objects of an individual actor, irrelevant of which client is used to create them in either direction, but bridging like this isn't really interop because e.g. replies from the other network would not be visible without client support
  • kopper@not-brain.d.on-t.workK
    15
    0
    i guess you could make a frontend that talks both APIs natively and picks which one to use depending on how you log in, which would avoid the going evil bit, but that increases complexity on the user's device a fair bit (likely manageable though) and still requires you to proxy the content of the other network as trying to fetch it from the client will either rate-limit/be slow or cause auth failures (e.g. an atproto login trying to fetch AP objects)
  • kopper@not-brain.d.on-t.workK
    15
    0
    now that i think about it, you would need actors and logins for both sides anyway if you're doing bridging, this is prolly not an issue
  • kopper@not-brain.d.on-t.workK
    15
    0
    bad ideas:

    xrpc/com.w3.activitystreams.proxyUrl?id=https://..
    {
        "endpoints": {
            "xrpcProxyUrl": "https://..."
        }
    }
  • jb@waf.moeJ
    3
    0

    a XRPC endpoint returning AS2-compatible data would be funny

  • kopper@not-brain.d.on-t.workK
    15
    0
    @jb i should look this up do lexicons have any places they can have unrestricted json in or would it have to be a string or something
  • jb@waf.moeJ
    3
    0

    lexicons do have unrestricted json, lexicon validation are there but its not required

  • kopper@not-brain.d.on-t.workK
    15
    0
    @jb no i think validation is important

    there is an unknown type but
    The (nested) contents of the data object must still be valid under the atproto data model. For example, it should not contain floats. Nested compound types like blobs and CID links should be validated and transformed as expected.
  • trwnh@mastodon.socialT
    33
    0

    @kopper nah it's good shit. i've been meaning to compile all my thoughts on the subject but you basically did it for me with this piece 👍


Citiverse è un progetto che si basa su NodeBB ed è federato! | Categorie federate | Chat | 📱 Installa web app o APK | 🧡 Donazioni | Privacy Policy

Il server utilizzato è quello di Webdock, in Danimarca. Se volete provarlo potete ottenere il 20% di sconto con questo link e noi riceveremo un aiuto sotto forma di credito da usare proprio per mantenere Citiverse.