Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.tlc.cellulari.android > #111711

LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola!

Show all headers | View raw

On 18/09/2026 , *BIG Umberto* wrote:
....
> Dunque...
> Gruppo it.test.
> Visualizzasioni raggruppate.
> Vedo una discussione "Trascrizione degli audio"  con omino e
>  numero 2, ma non ho mai partecipato.
> Infatti la apro (42 messaggi) ed io non ci sono infatti...
> Apro l'albero della discussione e pure lí, giustamente, non ci sono.
> Altra discussione, sempre su it.test, "fandanghef sii la mai AI"
>  omino con numerino 2, mai partecipato.
> Il motivo te lo dico io, si basa sul fatto che la mail del Barone
>  è uguale a quella mia predefinita (solo la parte mail), che non
>  uso ed ho impostato per occupare la voce.
>
> Ho sempre settato quello switch di non aggiornare.
> Quando replico ad una discussione, e faccio invio o annullo
>  l'invio, si porta sempre al primo post della discussione, anche
>  se io avevo replicato al 23esimo.

Ti copio qui sotto la risposta di Claude (lunga!)
Ti richiede anche un test, prima di intervenire...

Ho verificato entrambe sui sorgenti della 103. **Codice non toccato.**

**L'omino — Umberto ha ragione, e il codice gli dà ragione alla 
lettera.**
`reloadIdentityEmails()` costruisce `myEmails` come unione delle email 
di *tutte* le identità salvate, senza alcun legame con il server o il 
gruppo.
L'identità segnaposto è quindi attiva ovunque, e se un utente reale di 
it.test posta da quell'indirizzo ogni sua discussione diventa «una 
discussione in cui ho scritto».
Il numero 2 accanto all'omino, va detto, non sono i post suoi: è 
`repliesToMe`, le risposte ai miei post — coerente col resto, ma lui 
l'ha letto come «2 miei post»,
e in effetti quel numero non ha nessuna etichetta.

Questo caso **non si chiude stringendo il confronto**: gli indirizzi 
sono identici, nessun criterio può distinguerli.
Il rimedio *a costo zero*, subito e senza release, sarebbe quello di 
cambiare l'indirizzo di quell'identità inutilizzata con uno che non può 
esistere.
La RFC 2606 riserva il dominio `.invalid` proprio per questo, quindi 
`segnaposto@nereo.invalid` non collide con nessuno per costruzione.

**Verificando, però, è saltato fuori un difetto che Umberto non poteva 
vedere, e questo è serio.**
`eMioPost` è stata irrobustita nella 1.2.12 dopo l'audit — non cerca 
più l'indirizzo come sottostringa della riga From, lo estrae e lo 
confronta
ma **quella correzione non è mai arrivata nei tre punti che calcolano 
l'omino e `replyToMe`**: `ThreadFlatten` (albero e raggruppata) e 
`Repository` al sync usano ancora
`fromField.lowercase().contains(email)`.
Sei posti, due famiglie, tre con il criterio nuovo e tre con quello che 
l'audit aveva rimosso.
Il commento che tu stesso hai sopra `eMioPost`, scritto alla 1.2.11, 
diceva che:
"un criterio duplicato in quattro punti è esattamente il modo in cui i 
quattro punti finiscono per divergere": sono divergenti.
Conseguenze aperte oggi: `From: "umberto@suodominio.it" 
<chiunque@altrove.net>` fa scattare omino e conteggio.
E un indirizzo corto scatta dentro uno lungo (`mario@tin.it` dentro 
`supermario@tin.it`).

**Il ritorno al primo post.**
In `ArticleScreen` l'articolo mostrato sta in `var currentId by 
remember { mutableStateOf(articleId) }` — un `remember` semplice, 
seminato dall'argomento di rotta.
Spostarsi al 23° messaggio è un movimento interno allo schermo, non una 
nuova destinazione; ma andare alla schermata di risposta toglie 
`ArticleScreen` dalla composizione,
e al ritorno Navigation ripristina solo ciò che è `rememberSaveable`.
`currentId` riparte quindi da `articleId`, cioè l'articolo aperto dalla 
lista: la testa della discussione.
`ThreePaneHome` ha lo stesso schema per `selectedArticleId`, quindi se 
è questo il difetto si vede anche nei pannelli.
(Deduzione dal codice più il comportamento di Navigation-Compose.)

La sua (di BIG Umberto) precisazione sull'interruttore di aggiornamento 
è utile e scagiona il sospettato ovvio:
col sync spento la lista non cambia sotto i piedi, eppure la posizione 
si perde.
E il fatto che *invio* e *annulla* si comportino identici punta 
all'unica cosa che hanno in comune, il ritorno indietro.

NOTA:
Prima di toccare un `remember`, però, chiederei a BIG Umberto **una 
prova che può smentirmi**:
aprire il 23° messaggio, andare in una qualsiasi altra schermata e 
tornare indietro, senza rispondere.
Se salta lo stesso, la diagnosi è confermata; se salta **solo** dopo 
una risposta, la mia spiegazione è incompleta e va cercato altro.
Una correzione basata su un'ipotesi non verificata è già costata a 
questo progetto più di una consegna.

I piani per entrambi sono nel documento che ho scritto nel progetto.
In sintesi: per l'omino, rimedio `.invalid` subito e allineamento dei 
tre punti a `eMioPost` appoggiato alla prima release che esce per altri 
motivi,
perché i due casi che chiude sono di sicurezza, non di comodità;

per la posizione, la prova di BIG Umberto e poi `rememberSaveable`, con 
il rischio dichiarato da verificare (entrando in un articolo diverso si 
deve partire da quello nuovo,
non dal valore salvato).

-- 
          .:. MCSM .:.
-> posting from PC with MesNews <-

Back to it.tlc.cellulari.android | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

*NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-15 11:24 +0200
  Re: *NeReO* 1.3.7 - eccola! Macchia <TOGLIMI_la.macchia.nera@gmail.com> - 2026-09-15 12:11 +0000
  Re: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-15 17:39 +0200
    Re: *NeReO* 1.3.7 - eccola! Macchia <TOGLIMI_la.macchia.nera@gmail.com> - 2026-09-16 07:17 +0000
  Re: *NeReO* 1.3.7 - eccola! Bingo3331 <invalid@invalid.com> - 2026-09-15 16:06 +0000
    Re: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-15 18:24 +0000
    Re: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-17 17:01 +0200
      Re: *NeReO* 1.3.7 - eccola! Bingo3331 <invalid@invalid.com> - 2026-09-17 16:20 +0000
  Re:*NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433ZX.invalid> - 2026-09-18 01:05 +0200
    LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-18 12:00 +0200
      Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433.invalid> - 2026-09-18 12:14 +0000
        Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-18 16:06 +0200
          Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433.invalid> - 2026-09-18 19:32 +0000
          Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! BIG Umberto <user@2130706433.invalid> - 2026-09-18 21:44 +0000
            Re: LUNGO x BIG Umberto -> Era: *NeReO* 1.3.7 - eccola! MCSM <despammed@mcsm.anonaddy.me> - 2026-09-18 21:47 +0000

csiph-web