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

Fediverse & AI Coding Tools & Vibe Coding


Gli ultimi otto messaggi ricevuti dalla Federazione
  • definitely not a fan of this. tbh, there should just not be a global feed that new accounts see, because they see a lot of stuff they don't understand or know the community norms for, and that leads to bad engagement.

    read more

  • There is the Web Share API, and the future Web Share Targets API, but I think we could also align Web Share with FedCM and be able to say "I want to share to this type of application"

    read more

  • @reiver i think the disjunction between Object and Link was actually unnecessary. https://github.com/w3c/activitystreams/issues/666

    i also think there's too much emphasis on types when there really shouldn't be -- it's the *properties* that you end up using almost all of the time. pretty much the only types that actually matter are the Activity types (because you can't infer those).

    read more

  • @haitchfive

    I don't think it was me, but — it seems interesting.

    https://github.com/ha1tch/quertfy

    .

    read more

  • @reiver Did you and I discuss queryfy a while ago, or was it one of my other projects?

    Just wondering whether I owe you a heads up since queryfy has been bumped up to v0.3.0

    read more

  • With ActivityPub / ActivityStreams...

    To me, it feels like there should have been something that is a common parent of both 'Object' and 'Link'.

    That just had the "name", "nameMap", and "preview" fields (along with "id" and "type, of course) — since that is what 'Object' and 'Link' share in common.

    I'll just call this common parent: 'Entity'.

    ...

    It could have even been an opportunity to talk about how to handle unknown types.

    read more

  • @soapdog@toot.cafe hmm... just thinking aloud here.

    You posit in another post that the network effects inflate exponentially:

    > Push models are resource hogs that approach exponential growth in a large network like the fediverse

    That's not true. If you post a message then it sends a copy to each follower. That's linear growth. If you collapse recipients via shared inboxes you can reduce that further.

    If you're referring to the torrent of requests that happen if your post is shared (the "thundering herd" problem) then that's actually a PULL happening from those requesting instances!

    Secondly, in a pull model of AP, you would need to continually poll servers of all your followers so as to approach a real-time effect. You'd be polling servers over and over again, and many of them would have nothing new, with so much wasted traffic.

    If your expectations include semi real-time updates, the push model is much more performant, in my humble opinion.

    read more

  • @evan @mariusor @silverpill i think we probably need to revisit the user story of creating multiple objects at once, or more accurately, the user story of minting and binding multiple identifiers at once.

    read more
Post suggeriti
  • 0 Votes
    1 Posts
    17 Views
    And I found out why my #Peertube was running a bit ropey... The version was about 3 years out of date. Now on 8.0 and wow does it look better - and it also now works with the app. Thanks #fediverse!
  • 0 Votes
    9 Posts
    51 Views
    After I said bye to everyone night one, I left to head back to the Boiling the Ocean flavored AirBnB (what a sentence) and got to talk @cas and @tbernard and crew about some of the happenings in the @postmarketOS and @gnome worlds.
  • 0 Votes
    2 Posts
    11 Views
    @lqdev@lqdev.me hey, welcome to the Fediverse! Couple smol things... When I try to resolve your post by URL, I get a Person back, whoops! Not sure why on NodeBB, I see raw markdown. Was going to inspect source.content, but see #1 :sweat:
  • 0 Votes
    35 Posts
    90 Views
    xmpp is not "one standard" it's an extensible mess and no two people use the same client/server combination, leading to some kind of factorial explosion of mutually incompatible software. there are over five hundred XEPs and any given project has a unique view of which ones are "necessary" and which are "supported" and which are "deprecated" and which ones you should go to jail for even reading.xmpp has xeps for systems administration, internet of things shit, service discovery, and a million other things that should never have been shoved into a chat protocol, while the xeps that are intended to fix the actual issues that affect users are "deferred" because it's a hell of a lot easier to invent an entire new use case for xmpp than it is to fix any problems with existing xeps.this, combined with the excessively verbose markup, means that starting from scratch has two incredibly attractive benefits: one, you don't have to learn this tremendous bureaucratic protocol maze, and two, just about any wire format you can think of is going to perform better than xmpp over slow or intermittent network connections, which are the majority of internet connections.