Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

I'm curious what other devs think about this.

General Discussion
12 5 10

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @steve I think I’d be Quite Annoyed if a server did that when the C2S app I’m writing sent a Note. I’m asking it to Create a Note - I expect it to create a Note or fail to create a Note, not do some weird, unexpected third thing.

    I could maybe tolerate it adding a second type, but while my code can handle multiple types most ActivityPub software doesn’t seem to accept that kind of thing.

    read more

  • @jerger @steve

    Keeping msgs immutable is a general best-practice, I gather.

    In the case you mention it becomes confusing to still use client/server terminology. You have a full actor on the client's side, and when it sends a msg it acts in server/S2S role.

    Btw, in that scenario we do not have to make the distinction client + server anymore, as we have just actors communicating with each other. Then we can think in terms of the actor model, and honor its qualities.

    A client sending to the server's outbox is then analogous to an actor sending to another actor's inbox. That is a one-way msg exchange usually, fire and forget (esp. in a pure event-driven architecture... which the current fediverse is not). The remote actor is not responsible for keeping the Activity (event) in its server-outbox / actor.inbox. That corresponds to the spec part "may disappear at any moment".

    read more

  • @steve If you consider also peer 2 peer networking as an option, your client might switch it's role and act as a server.

    In this case it having such a different inside outside mapping for objects will become confusing.

    read more

  • @mariusor Yes, I'm seeing it in a real server while doing C2S testing/exploration. In this case, the server can handle Note and Article, in general, so I don't the rationale yet for the conversion. It's in pre-release code so it may or may not be intentional.

    read more

  • @steve

    lets say there is a local-server sending this create/note to a distant-server.

    Whatever object distant-server creates internally I am very neutral.

    But I am very engaged from

    1. viewpoint of local-server I expect to get feedback about a note object & being able to deref a note object.
    2. viewpoint of distant-server user I expect to see a object behaving like a note.

    In a bottom line - naming a note different makes absolutely no sense at all ...

    read more

  • @steve but did you actually observe this behaviour in any servers? What made you ask the question?

    To me it sounds very implausible, because the server *actively* needs to do something instead of piping the received activity directly to its recipients. Is it a case of "the server doesn't render Note objects" so they silently convert to something they do?

    Even that's implausible to me, because the same code can be used to render both...

    read more

  • @mariusor Like you said, I'm not sure the user (rather than the client dev) cares about details like the AP object type. However, they may care from a UX perspective if their messages are silently dropped (during S2S federation because the type was changed). And if they do care, they'll probably complain to the client developer who didn't cause the problem. 😉

    read more

  • @steve the problem as I see it is only with the "misrepresentation of the user's intention". Which might, or might not cover the aspect that you referred to...

    read more
Post suggeriti
  • 1 Votes
    4 Posts
    14 Views
    @julian @incise Now it is
  • 0 Votes
    1 Posts
    8 Views
    Looks like @todd won the #ActivityPub experiment.
  • 0 Votes
    1 Posts
    11 Views
    The major feature in v3.2.0 of Ktistec is thread analysis. The previous release, v3.1.2, added support for viewing threads from Lemmy communities. I follow the Open Source community, which leads to many large threads. The thread on FFMpeg and Google has 112 posts and is still growing.Thread analysis helps me navigate these extensive conversations. It includes: top contributors, a timeline histogram, and notable branches.The analysis applies several heuristics to identify interesting branches of the main thread. “Interesting” is subjective, but the algorithm currently looks for sudden bursts of activity and highlights those areas. Ktistec uses this to create a table of contents that links directly to those branches. Clicking on one of these links takes you to a branch-only view that focuses on the selected part of the thread.It's fast—I anticipated needing to cache analyses, but analyzing a thread with over 400 posts takes only about 50 milliseconds on my production server.Figure 1: Screenshot of the final design. Notable branches link to subsets of the thread.This release also addresses an object visibility regression that was introduced in a previous version.Full ChangelogAddedThread analysis that displays key participants, a timeline histogram, and notable branchesNew MCP tools: analyze_thread and get_threadFocal point rendering support for image attachmentsFixedRegression in object visibility affecting replies to threadsChangedEnhanced MCP tool details for likes, dislikes, and announcesImproved cookie security.#ktistec #fediverse #activitypub #crystallang
  • 0 Votes
    1 Posts
    11 Views
    #YourInControl #loops #activitypub #fyp #OpenSource #tiktok