Come on, #Fediverse!
Fediverso
8
Posts
4
Posters
41
Views
-
Come on, #Fediverse!
If you're bold enough to
- leave X, Instagram and Facebook
- close your Gmail account and go with privacy respecting services
- avoid Amazon and go shopping locally or on small e-commerces
- stop using Google search and you prefer meta searches or privacy oriented ones...
...then you're ready also to buy a real Linux phone.
Let's make the new Jolla phone break through 10k orders, let's make it real!
https://commerce.jolla.com/products/jolla-phone-preorder
#jollaphone #sailfish #linux #smartphone #eualternatives #opensourcesustainability #privacy #digitalsovereignety
Edit: no, I'm not affiliated with @jolla that's my own personal initiative!
-
Come on, #Fediverse!
If you're bold enough to
- leave X, Instagram and Facebook
- close your Gmail account and go with privacy respecting services
- avoid Amazon and go shopping locally or on small e-commerces
- stop using Google search and you prefer meta searches or privacy oriented ones...
...then you're ready also to buy a real Linux phone.
Let's make the new Jolla phone break through 10k orders, let's make it real!
https://commerce.jolla.com/products/jolla-phone-preorder
#jollaphone #sailfish #linux #smartphone #eualternatives #opensourcesustainability #privacy #digitalsovereignety
Edit: no, I'm not affiliated with @jolla that's my own personal initiative!
Talking about getting a linux phone is easy, but the prices are a huge problem.
I usually don't pay more than 150 euros for a phone, but I've paid roughly 175 euros for my current one.
Paying more than 250 euros for a phone is madness. No matter its operating system, no matter its repairability. I don't care. Most people can't afford rent and food right now.
-
Talking about getting a linux phone is easy, but the prices are a huge problem.
I usually don't pay more than 150 euros for a phone, but I've paid roughly 175 euros for my current one.
Paying more than 250 euros for a phone is madness. No matter its operating system, no matter its repairability. I don't care. Most people can't afford rent and food right now.
@anominominominous
I get your point. Is is easy to talk about everything.
Talking is always easy, but I didn't mean to put this as an ethical imperative, that good willing people should buy, but as a possible alternative for those who are willing and have the possibility to buy it.In the end, a phone is just a phone, it could never define a person.
But if the concept is adopted, the wider it is, the more offer for even more economic devices will be possible.
-
Come on, #Fediverse!
If you're bold enough to
- leave X, Instagram and Facebook
- close your Gmail account and go with privacy respecting services
- avoid Amazon and go shopping locally or on small e-commerces
- stop using Google search and you prefer meta searches or privacy oriented ones...
...then you're ready also to buy a real Linux phone.
Let's make the new Jolla phone break through 10k orders, let's make it real!
https://commerce.jolla.com/products/jolla-phone-preorder
#jollaphone #sailfish #linux #smartphone #eualternatives #opensourcesustainability #privacy #digitalsovereignety
Edit: no, I'm not affiliated with @jolla that's my own personal initiative!
-
This could be a nice topic to follow: https://forum.sailfishos.org/t/jolla-phone-2026-for-everyday-use-in-italy/27275
-
This could be a nice topic to follow: https://forum.sailfishos.org/t/jolla-phone-2026-for-everyday-use-in-italy/27275
-
@oblomov
However. I'll still keep an older Android phone for banking and public administration applications, but just because most of those apps are mobile-only. I never needed an home banking app on my phone, but, it seems that some banks make it impossible to avoid it. I never needed school or e-signature apps or even medical apps on my phone, even if recon that those may be useful for someone. But they shall not be available only on phones. -
@oblomov
However. I'll still keep an older Android phone for banking and public administration applications, but just because most of those apps are mobile-only. I never needed an home banking app on my phone, but, it seems that some banks make it impossible to avoid it. I never needed school or e-signature apps or even medical apps on my phone, even if recon that those may be useful for someone. But they shall not be available only on phones. -
undefined 77nn@goto.77nn.it shared this topic on
undefined oblomov@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@PortaFed
@julian
Why wouldnt the whole export object be signed? If an object is missing, the merkle root wouldnt match and you wouldnt be able to do partial validation anyway. I could have missed something on the strategy there
-
@jonny @julian You're right on all three points. Updated the spec: destination_did is now optional the backup-before-shutdown case is the primary use case and requiring a destination in advance was a mistake.
Added Section 5.1 explaining why the Merkle tree exists alongside per-object signatures: the signatures prove per-object authenticity but not completeness. A Merkle root over the full set detects silently dropped objects.
Added Section 8 explicitly scoping this as an export/import substrate
-
@jonny@neuromatch.social honestly good for you for investing the time to critique this knowing it's AI (adjacent or wholesale) involvement.
-
@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.
-
@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:
-
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.
-
@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.
-
@jonny@neuromatch.social tracks doesn't it š
