Se for deg en skaper som bytter tjeneste. Artiklene importeres, men bildene blir igjen. Kontonavnet er det samme, men følgerne finner ikke den nye profilen. Bokmerkene er eksportert, men peker alle til det gamle nettstedet. En eksportfil og en komplett opplevelse etter flytting må kontrolleres separat.
Derfor er åpen publisering interessant: «hva skjer når brukeren slutter?» blir et tidlig produktspørsmål, fremfor at eksport bare er en knapp i innstillingene.
Åpen publisering får konkrete bruksområder
I juni 2026 presenterte Bluesky bloggapplikasjoner knyttet til Standard.site og diskuterte skriving og flytting på et felles teknisk grunnlag. Eksemplet viser at én protokoll kan støtte ulike innholdsprodukter, ikke bare flere grensesnitt til samme app. Blueskys introduksjon
Et eksempel i ett økosystem beviser likevel ikke samvirke mellom alle plattformer. Sjekk datatyper, utvidelsesfelt og flytteprosesser i begge ender. Et felles teknologinavn erstatter ikke en faktisk import- og gjenopprettingstest.
Skill identitetskontinuitet fra innholdsbevaring
W3Cs DID Core beskriver desentraliserte identifikatorer og kontrollmekanismer. En identifikator hjelper systemer å kjenne igjen samme aktør, men bevis på kontoeierskap bevarer ikke automatisk historisk innhold, mediekopier eller programtilstand. W3C DID Core
Spør separat om brukeren fortsatt kan bevise kontroll, hvordan den nye tjenesten finnes, hvordan historiske lenker holdes koblet, og hva som kan gjenopprettes dersom den gamle tjenesten blir borte. Dette blir lettere konkrete funksjoner enn et generelt løfte om at «brukeren eier kontoen».
Gjenoppretting må også være forståelig. Nøkler, gjenopprettingsopplysninger og leverandørhjelp har ulike vilkår. En ideell prosess i utviklerdokumentasjonen er ikke nok hvis vanlige brukere først møter begrepene under flyttingen.
Eksportpakken må forklare grensene sine
AT Protocols veiledning behandler brukerlagre, mediefiler og private innstillinger separat, beskriver endring av identitetsrelatert tjenesteinformasjon og nevner at noe tilstand ligger i andre tjenester. Selv et økosystem med en tydelig flyttemekanisme trenger kontroll punkt for punkt. AT Protocols flytteveiledning
For innholdsapper under eget merkenavn kan tabellen avgrense leveransen:
| Datatype | Brukerens behov | Foreslått kontroll |
|---|---|---|
| Konto og identitet | Å bli gjenkjent etter byttet | Innlogging, identitetskobling og oppdagelse av nytt sted |
| Artikler og poster | Bevart tekst, tid og referanser | Sammenlign antall, felt og representativt innhold |
| Bilder, lyd og video | Vedlegg som faktisk åpnes | Avstem medielisten og hent filene |
| Brukerrelasjoner | Fortsatt oppløsning av følging og referanser | Sjekk relasjonstyper og målidentiteter i begge ender |
| Private innstillinger | Preferanser, meldinger eller tilstand som kan mangle | List inkludert, utelatt og gjenopprettingsmetoder |
Dette er et designråd, ikke et universelt format for alle protokoller. Følging, anbefalingsinnstillinger og private meldinger kan ikke erklæres fullstendig flyttet bare fordi noen offentlige innlegg kan importeres.
Flytteøvelser avdekker skjulte avhengigheter
Opprett en egen testkonto med ren tekst, artikler med vedlegg, kryssreferanser og tydelig bekreftbare brukerrelasjoner. Kjente eksempler gir kontrollmål uten forsøk på reelle brukerdata.
Registrer koblinger før og etter flytting: opprinnelige og nye identifikatorer, vedleggsplasseringer og felt som ikke støttes. Antallet importer er bare ett resultat. Åpne innhold, spill av medier, sjekk referanser og bekreft at feil kan behandles enkeltvis.
Simuler også avbrudd. Kan arbeidet fortsette når eksporten er ferdig, men bare halvparten av vedleggene er lastet opp? Lager ny import duplikater? Rapporteres en innstilling som ikke støttes, eller forkastes den stille? Dette avgjør ofte om flytting er egnet for faktiske brukere.
Behold en brukbar gammel kopi og gjenopprettingsvei til kontrollen er ferdig. Bytte av tjenestested og sletting av gamle data bør være separate handlinger. Brukeren må vite når retur er mulig og når følgene er irreversible.
Forklar forskjeller i stedet for å skjule dem
Åpne protokoller krever ikke identiske funksjoner. Én app kan prioritere lange tekster, en annen korte meldinger eller mediebiblioteker. Forklar hvilke felles funksjoner som flyttes, hvilke særfunksjoner som bevares som tilleggsdata, og hvilke som bare kan arkiveres.
En flytterapport trenger mer enn «vellykket» eller «mislykket». Skill verifiserte elementer, elementer uten støtte og elementer som krever brukerhandling, så skaperen kan velge før viktige data viser seg å være borte.
AlphaBizs offentlige materiale gir et utgangspunkt for apper under eget merkenavn. For slike apper er portabilitet et designspørsmål: hvordan bevarer innhold og relasjoner verdien når merke og grensesnitt endres? AlphaBizs prosjektinformasjon
Artikkelen beskriver ikke AT Protocol eller Standard.site som eksisterende AlphaBiz-integrasjoner. Neste steg er å avgrense appens data og kontrollere dem i etterprøvbare flytteøvelser. Start med hva brukeren ikke må miste, og del kravene i prosjektdiskusjonene.