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

Journalismus jenseits von Big Tech: unser Report ist da!

Fediverso
10 6 16

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @jonny@neuromatch.social honestly good for you for investing the time to critique this knowing it's AI (adjacent or wholesale) involvement.

    read more

  • @julian @PortaFed
    giving a further read: I can't really imagine a case where someone would a) regularly be creating signed backups and also b) know in advance where you wanted to migrate to to set the destination_did. Like if this is for the case where the instance has shut down, you might have some signed backup, but you probably haven't planned in advance where you would want to migrate, and if the instance is down you wouldn't be able to create the migration object after the fact.

    the validation strategy for the export is sort of mystifying to me. if the whole object is signed, then why would you need a merkle tree for objects and also an object count? if the contents of the object have changed post signing, then the signature validation will just fail and those are irrelevant.

    true to form for LLM generated documents, several critical things are left undefined, like what last_accepted_sequence is or how that works.

    probably the most important problem is that it's not really clear how all other instances are supposed to handle this, which is the entire hard part of a migration spec. Like, if the purpose here is to preserve identity, then you would need to have all the other instances come to see the new identity as being equivalent to the old identity, and there's no discussion of how that process works for third-party instances at all. like e.g. in FEP-1580 i had to spend a long time gaming out scenarios for how third party instances would handle a move event.

    so without that it's not really an account portabiltiy spec, it's an account export/import spec, which is fine, just not really needed since signing objects and collections (which this spec should use anyway) is already described by other specs.

    read more

  • @silverpillThank you , these are important corrections and I appreciate you taking the time.
    You're right on both points. I'll update the spec to reflect that FEP-ef61 authority is not actor-rooted in the way I described, and that migration is possible via outbox export-import. I was overstating the gap.
    The distinction I was trying to draw is narrower:

    read more

  • @PortaFed

    I have a couple of comments regarding the spec https://codeberg.org/portafed/portafed/src/branch/main/portafed-spec/spec.md

    It contains a comparison with FEP-ef61, but it is not quite correct:

    - FEP-ef61 identity is not actor-rooted. The closest equivalent of FEP-ef61 identity in normal ActivityPub is a server with a domain name. A single FEP-ef61 authority can manage multiple actor documents.
    - FEP-ef61 does not lack a migration flow. Strictly speaking, it doesn't need one, because data is not attached to a server and can be continuously synchronized between multiple servers. But a more familiar migration flow is also possible via outbox export-import.

    @lutindiscret

    read more

  • @benpate That would be great and happy to contribute wherever it fits.
    My guess on the scope decision is the same as yours: hostile-server recovery is genuinely harder, and a cooperative spec is already a lot to get right. Makes sense to tackle it separately.
    Take your time reading. I'll put together a short write-up of how MigrationProof could slot into the existing spec easier to react to something concrete than to an abstract pitch.

    read more

  • @jonny@neuromatch.social tracks doesn't it 😝

    read more

  • @julian
    @evan @benpate @PortaFed
    Can't make heads or tails of this one

    read more

  • Warm up the fire! We're LIVE!

    Summer in Winter: Norcal Gma 2's Journey with her Dog - E79

    #owncast #streaming #interview #fediverse #fedi #people #show #firesidefedi #FsF

    https://stream.firesidefedi.live

    read more
Post suggeriti
  • NodeBB v4.9.0 — A Whole New /world!

    Fediverse fediverse
    3
    1
    0 Votes
    3 Posts
    3 Views
    Ah! Cool, thanks for sharing that forum with me. It looks like this forum is using a couple of tools that NodeBB provides to get content: crossposting and moving topics. Both those actions "borrow" content from other communities: [image: 1772472942066-8978c9b5-8580-417e-ba4f-4d1d7d3a7694-image.jpeg] The good news is that it looks great in NodeBB, you get to see other comments and topics from elsewhere on the fediverse. The bad news is that the cross-federation of this stuff to other threadiverse software is still not well defined. Piefed for example, supports topic moving (so, those "world" topics should show up in Piefed), but @rimu@piefed.social @nutomic@lemmy.ml and I have not extensively tested that logic. Cross-posting is NodeBB-only at the moment, and the three of us (plus the mbin folk) have not started talking about what this might look like between instances. So that is why that community looks empty for you on Piefed... which is unfortunate, but we're working on it!
  • 0 Votes
    1 Posts
    11 Views
    More progress on the AP implementation on my site. I got HTTP signature verification on Follow activities working and started the groundwork to migrate from my current instance to my website. Some things I want to do before migrating: 1. Export my archive, I'm especially interested in preserving who I'm follows and bookmarks. 1. For bookmarks: Create a page on my site that links to the bookmarks. 1. For follows: Create an OPML file linking to their RSS feeds and add those feeds to my feed reader. One thing I will miss after I retire my instance is the timeline. I always discover interesting posts and people that way. My plan is to follow RSS feeds for tags that I'm interested in. I know it's not as good or spontaneous as the timeline but it's a way to stay engaged in the conversation. Also, my site effectively will work one-way for now. I don't have a way to receive replies or DMs, nor do I have a way of replying to people directly from my site. Maybe that's something I'll add later on but not a priority at the moment. My main priority at the moment is to maintain a presence in the Fediverse without having to maintain my own instance. I know technically I could just join someone else's instance, but I don't want to create yet another account nor become a maintenance burden for someone else. More importantly though, I want my website to be my digital hub, with protocols like ActivityPub, Nostr, and AT Protocol serving as spokes to reach different networks. My content and identity remain on my site, independent of any single platform. If any protocol or network disappears, my content and identity remain intact.
  • 0 Votes
    2 Posts
    5 Views
    @mapache @badgefed looks promising! looking forward to trying this out.(I guess there may be an issue with the acknowledgement on the Mastodon side as this shows pending?)
  • 0 Votes
    2 Posts
    14 Views
    @GillesLeCorre2 bonne journée a toi.