Citiverse
  • 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 👍

  • raphael@mastodon.communick.comR
    1
    0

    @kopper

    > separate data hosting from data interpretation
    https://activitypub.mushroomlabs.com/topics/reference_context_architecture/

    > with many objects and slow connections the overhead of creating new http requests would add up significantly

    GraphQL and/or SPARQL

    > iterating through my inbox every time i open my “home timeline”

    The same your email client works: sync the inbox, create index view in the clients. That's at least what I am doing for my C2S client. My problem now is that I wish that C2S had a way to say "clear my inbox"

  • kopper@not-brain.d.on-t.workK
    15
    0
    @raphael
    GraphQL and/or SPARQL
    these can be valid options but they add complexity to the C2S server, which is both the part that individual users would want to self-host AND also the part already burdened by having to deal with the traffic bursts caused by things like boosts and replies by large accounts. i think if a query endpoint were to be created it should be maintained by a client (at least architecturally, if an implementation wants to merge them both it's their choice!)
    The same your email client works: sync the inbox, create index view in the clients.
    this still does not address the problem. an actor's inbox contains way more than just the Posts on their Timelines (and will do even more if AP were to be the Everything Protocol it dreams on being). you'd need to load pages upon pages of as:Like, as:EmojiReact (and as:Undo for both), as:Listen (e.g. following someone using pleroma scrobbles), various as:Add as:Remove as:Update as:Delete "management" activities for unknown objects, and so on which will swiftly get thrown away but still end up consuming latency (especially after a few days of being away) and often-costly mobile bandwidth

    email clients work because your inbox Only contains Emails. the data you get is pretty much all relevant, you don't end up discarding huge chunks of it

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.