GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 02:52:46 JST Hrefna (DHC) Hrefna (DHC)

    Some theorycrafting for a social network that is _like_ AP-derived systems, but is not based on AP.

    First, some premises:

    1. I am following a traditional actor pattern here. When I say "actor" I do not mean "AP actor" but rather an object with an inbox and a name that has some black box mechanism behind it.

    2. I am _not_ discussing security or half a dozen other things that would be vitally important for a full proposal.

    3. I am very, very rarely going to be discussing payload.

    1/

    In conversation about 5 months ago from hachyderm.io permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 02:56:38 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      First, let's define a _message layer_. Here we have a concept of an _actor reference_.

      An actor reference has:

      1. An inbox.
      2. A URI id that just returns this reference object.
      3. A structured type field, indicating what class of messages it takes and some basic behaviors around it. This can be simple or relatively complex

      These are functionally immutable references. A _user_ is a distinct concept and may change actors around at any point. They can also refer to a central actor via DNS

      2/

      In conversation about 5 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:00:18 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      _Messages_ are ephemeral, immutable objects that contain the following information:

      1. An incrementing id that is unique per server.
      2. A server.
      3. A URI for the _payload being referred to_.
      4. A type.
      5. Any routing information.

      So I could say:

      Create {
      id: <uuidv7>
      server: <uri>
      canonical_uri: <uri>
      from: <originating user>
      to: [<list of users>]
      }

      That's it. No payload. There are other fields that may be interesting here, but we're being a bit minimalist.

      3/

      In conversation about 5 months ago permalink

      Attachments


    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:02:52 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      Now when someone goes to the server's canonical URI you'll get a full AS2 object (or whatever) in some normalized form. The details don't matter so long as the canonical_uri matches the id.

      So you can see how this starts to develop:

      Alice sends Bob a message saying that she created a Note (1).
      Alice sends Bob a message saying that she created a Note (2).
      Alice sends Bob a message saying that she created a Note (3).
      Alice sends Bob a message saying that she updated a Note (1).

      4/

      In conversation about 5 months ago permalink

      Attachments


    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:04:49 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      So now we have a message passing system and an actor reference. Cool.

      But what does a user look like? How about a server? What about these payloads?

      Well. For that we need a _data layer_.

      5/

      In conversation about 5 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:07:44 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      The data layer is responsible for serving the payloads of objects.

      We _could_ have Bob go to alice and systematically call each message in a row, but that's a waste of time and energy.

      Better would be to provide a single endpoint on the server where I can say "give me all objects from Alice that were sent to Bob or are marked as:Public starting with id <foo>"

      This may be attached to Alice directly but it doesn't have to be: it could be a generic per-server endpoint.

      6/

      In conversation about 5 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:12:05 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      (nb. I am cheating a bit with terminology, technically this would be a _service layer_ not a data layer, but data layer is cleaner for what we're talking about and I don't want confusion with the message layer).

      The core here is that this is a single, paginated request that fetches _objects_ or _payloads_. The type can be content negotiated with HTTP, it can use different wire formats, all of that is less important.

      7/

      In conversation about 5 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:15:52 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      Now what about the user?

      Users do not exist in the message layer. They _are not actors_.

      Rather they _contain_ actors.

      You get the user information from anything. DNS, a credentials server, I don't care about that for right now, but it has on there an inbox object, or maybe multiple named inbox objects, and they have actor _references_ (see above) that you can now send messages to.

      8/

      In conversation about 5 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:17:46 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      Now it does not matter if the same actor serves multiple users, or multiple inboxes for a user, or whatever else. It does not matter if they are all distinct actors that then forward their information to a central actor that then fans them out to other servers entirely.

      What matters is that you fetch the user object from a canonical store and it tells you where the actors live and information like how to fetch posts from this person.

      9/

      In conversation about 5 months ago permalink
    • Embed this notice
      Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 28-Dec-2024 03:19:32 JST Hrefna (DHC) Hrefna (DHC)
      in reply to

      One could also envision a series of redirects.

      My information is stored on server <foo> but all of my canonical ids reference hrefna.dev/whatever.

      Why? Because I'm proxying the calls over to a backend server that I reserve the right to change in the future.

      There are a thousand things you can do from here, but basically we now have a basic lightweight framework for a scalable, message-passing-based social network.

      10/10

      In conversation about 5 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.