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

BONJOUR LE #fediverse ❤️🧡💛💚💙💜❤️🧡💛💚💙💜

Fediverso
24 9 42

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
  • 0 Votes
    11 Posts
    53 Views
    @NovemDecimal look for topics relevant to your interest, browse the federated timelines, spot posts that are interesting, follow people, contribute positively to discussions when you can
  • FEDIVERSE DECISION TIME

    Fediverso fediverse mastodon
    17
    0 Votes
    17 Posts
    38 Views
    @stefano thanks. I'm pragmatic about levels of engagement here and elsewhere. Looking at other instances' local live feeds, in isolation, was … erm … I'm not sure how to describe the overall experience, but it was worth it.
  • 0 Votes
    1 Posts
    12 Views
    实例(ControlNet Social Space; 简称CSS)搭建的告一段落了,稍微总结一下:1. 选型阶段(#ActivityPub 生态对比)先稍微 review 一下现在已有的 #fediverse 平台,选择以 ActivityPub 作为协议的平台,毕竟联邦的话还是得尽可能有更多人用才行。类似于用于实时通讯的 matrix。然后评估了 #Mastodon / #Pixelfed / #Pleroma / #Misskey / #Sharkey 等,确认不同实现可互联互通(Pixelfed ↔ Mastodon 等)。然后偶然得知 #Threads 也是Fediverse中的一员。然后,研究“主域 abc.xy 显示身份、实例跑在 social.abc.xy”的可行性。结论是这样不靠谱,所以放弃了。。最终决定考虑到Sharkey比起Misskey有一些不错的feature就选了Sharkey。2. 部署与运行按官方文档与 docker compose 在用 #Unraid 系统的 #NAS 上部署 Sharkey。邮件服务器使用free-tier的#Resend 。然后还稍微折腾了一下如何设置管理员。3. 联邦互动与内容获取学会了站内搜索关注远端用户(用 @user@domain 或贴对方资料页 URL 解析)。然后是关注 Threads 用户的实操(前提对方开联邦)。但是这时候实例里没有什么联合,时间线完全没东西,就考虑有没有订阅别人一整个时间线的方法,好像不太可行。4. 存储与图片体积了解到 Misskey/系每用户默认 100 MB 网盘,附件都会落地到服务器(非纯外链)。而且没办法通过引用外链来渲染图片。试了一下本地上传+压缩,发现会自动压缩到webp,勉强还行。6. 二步验证(2FA)故障 & 解决刚才开启 2FA 后出现“authentication failed”,连恢复码也无效,日志报:Endpoint: i/change-password ... {"message":"authentication failed", ...}尝试各种排查均失效,最后只能直接改数据库里的,把 2FA 关掉,然后再重新绑定 2FA和passkey。7. 默认不显示在线状态发现这个需要在用户设置里修改,并且没找到如何让用户默认就是显示的,只能先放弃了。8. 注册与邀请码觉得发放多个一次性邀请码麻烦,想找可重复使用的邀请码。结果发现不行,只支持一次性的,感觉除非自己之后魔改一个web服务用于自动发放邀请码并且自动填写,不然想分享到别的群里,确实有点难度。也没有那种私人邀请的链接。TODO: 未来感觉还是有很多可以做的1. 能够自动探索别的实例的某些方法,找到一些有意思的用户去follow。2. 部署一个chat agent用于增强活跃度,但是又不能感觉像是纯骚扰,如何设计是个问题。3. 做一个方便remote follow的工具
  • 0 Votes
    1 Posts
    16 Views
    I requested a public figure turn on #threads #activityPub #Fediverse bridging by finding a contact email address on their webpage and including this message.Greetings,I'm writing to request that you turn on the fediverse bridge on your Threads account. This will allow me, and others on the 'verse, to follow your posts and updates without having to agree to Meta's EULA and give them access to personal data nor use freedom denying closed source non-free software that I don't want to.They have instructions for how to do so here: https://help.instagram.com/760878905943039Feel free to copy/paste if it makes it easier for you to do similarly. Let me know if you get any positive responses and any improvements to this general message that are made. Maybe we can create something that makes it even easier for others to do similarly.