Cioè Signal sta sul Cloud di Amazon
Uncategorized
26
Posts
6
Posters
0
Views
-
@ju la cifratura end to end, che su Signal sappiamo per certo funzionare, rende, da un punto di vista della sicurezza completamente indifferente il fatto che il sistema giri su di un server o un altro. I messaggi sono cifrati da end user a end user. Il massimo che potrebbe avere AWS sono gli IP degli utenti, che comunque non ha, dato che il frontend su Signal mi risulta essere da tutt'altra parte (detto ciò è da un po' che non analizzo che cosa fa il mio traffico Signal). Per quanto io appartenga alla categoria di quelli che vorrebbere vedere AWS scomparire in un mare di fiamme il fatto che un servizio come Signal debba girare su AWS per me rimanda a un problema più importante: per essere autonomi servono i soldi. Tanti soldi.
-
@ju la cifratura end to end, che su Signal sappiamo per certo funzionare, rende, da un punto di vista della sicurezza completamente indifferente il fatto che il sistema giri su di un server o un altro. I messaggi sono cifrati da end user a end user. Il massimo che potrebbe avere AWS sono gli IP degli utenti, che comunque non ha, dato che il frontend su Signal mi risulta essere da tutt'altra parte (detto ciò è da un po' che non analizzo che cosa fa il mio traffico Signal). Per quanto io appartenga alla categoria di quelli che vorrebbere vedere AWS scomparire in un mare di fiamme il fatto che un servizio come Signal debba girare su AWS per me rimanda a un problema più importante: per essere autonomi servono i soldi. Tanti soldi.
per essere autonomi servono i soldi. Tanti soldi.
Sì e no.
Qui è dove secondo me la decentralizzazione fa la differenza: tante piccole istanze decentralizzate necessitano molti meno soldi di una grossa unica istanza centralizzata.
Questo è un punto su cui insisto abbastanza da diverso tempo: l'obiettivo non dovrebbe essere costruire un WA alternativo, perchè semplicemente non lo si può fare senza avere dietro una enorme quantità di risorse.
Invece l'obiettivo dovrebbe semplificare la possibilità per ogni utente di avere la sua piccola istanza familiare.
L'ostacolo vero su cui lavorare è la necessità di avere almeno una base di competenza informatica per poter gestire la propria istanza di qualsiasi cosa.
Vabbeh, sto divagando...
Il punto è che se fai una miriade di piccole istanze servono meno soldi e meno risorse o perlomeno risorse più diffuse.
-
@ju si, ok, d'accordissimo. Per farlo servono a) competenze informatiche diffuse e per queste intendo la capacità di gestire in modo verticale l'intero stack (dalla scelta degli UPS al deploy delle nuove versioni passando per i backup) b) competenze informatiche che siano a disposizione della comunità c) risorse per mantenere il tutto (energia, dischi che si rompono, banda ecc). Per fare questo servono anni, ed è una cosa su cui sia io che altri del mondo degli hacklab siamo pure impegnati da tempo. I frutti sono stati, a ora, scarsi. E questo per una miriade di fattori che volendo posso pure esplodere (miopia politica da parte delle strutture militanti/attiviste in cui agiamo, autoreferenzialità nostra ecc). Nel frattempo preferisco che un sistema come Signal, molto general purpose e molto accessibile, sia diffuso.
-
@ju si, ok, d'accordissimo. Per farlo servono a) competenze informatiche diffuse e per queste intendo la capacità di gestire in modo verticale l'intero stack (dalla scelta degli UPS al deploy delle nuove versioni passando per i backup) b) competenze informatiche che siano a disposizione della comunità c) risorse per mantenere il tutto (energia, dischi che si rompono, banda ecc). Per fare questo servono anni, ed è una cosa su cui sia io che altri del mondo degli hacklab siamo pure impegnati da tempo. I frutti sono stati, a ora, scarsi. E questo per una miriade di fattori che volendo posso pure esplodere (miopia politica da parte delle strutture militanti/attiviste in cui agiamo, autoreferenzialità nostra ecc). Nel frattempo preferisco che un sistema come Signal, molto general purpose e molto accessibile, sia diffuso.
Ma perchè non mettere risorse in questo invece che premiare il fatto che Signal metta risorse da tutta un'altra parte?
Poi dico, perchè a questo punto diffondere Signal e non per esempio XMPP?
XMPP è facile da usare, diffuso, open-source, criptato, privacy oriented e self-hostabile se uno ha le competenze per farlo oppure ci sono diverse app che offrono la possibilità di crearsi un account.
-
@ju perchè le risorse sono limitate e quindi tocca operare delle scelte. Che non significa non usare e non diffondere XMPP o Deltachat, significa che alloco maggiori risorse su dove, in seguito a un'analisi, penso che sia più perseguibile l'obbiettivo. Signal se lo installa e se lo configura chiunque, XMPP finisce che devo fare io il giro dei cellulari da configurare e riconfigurarglielo pure ogni volta che cambiano cellulare. È sostenibile? No. Quindi, se ho energia 15, preferisco investire 10 nel dire "installetevi Signal e piantatela di usare WA che vi vende alle guardie" e 5 in "e comunque ci sono ulteriori alternative decentralizzate". Come già detto un ecosistema è forte quando è diverso per cui non sto a inseguire solo Signal o XMPP ma sono costretto a operare scelte in base alla scarsità di risorse.
-
@ju tra l'altro non si tratta di "premiare Signal", si tratta di individuare il sistema più efficiente rispetto allo scopo che ci si da. Il mio scopo in questo momento è che quante più persone possibile siano in grado di comunicare con un sistema di IM in modo sicuro senza avere grandi capacità tecniche. Signal risponde a questa esigenza, le alternative proposte no. E aggiungo anche che siccome io sono dell'idea che i sistemi funzionanti debbano essere pagati consiglio pure di donare, io lo faccio su base mensile, a Signal in modo da garantire uno sviluppo continuativo e augurandomi che siano in grado di rendersi autonomi da sistemi di cloud.
-
@ju tra l'altro non si tratta di "premiare Signal", si tratta di individuare il sistema più efficiente rispetto allo scopo che ci si da. Il mio scopo in questo momento è che quante più persone possibile siano in grado di comunicare con un sistema di IM in modo sicuro senza avere grandi capacità tecniche. Signal risponde a questa esigenza, le alternative proposte no. E aggiungo anche che siccome io sono dell'idea che i sistemi funzionanti debbano essere pagati consiglio pure di donare, io lo faccio su base mensile, a Signal in modo da garantire uno sviluppo continuativo e augurandomi che siano in grado di rendersi autonomi da sistemi di cloud.
@lorcon @ju premetto che parlo di XMPP solo perche lo conosco bene e perche non conosco gli altri sistemi federati di chat. La tua esperienza con XMPP (canonico Conversations su Android, Gajim o Dino su desktop, Converse.js su web) è cosi negativa?
Ormai da tempo dalle mie parti buona parte dei giri di movimento comunicano con quel protocollo senza troppa assistenza da parte degli hacklab locali.
Gli hacklab mettono su i server e costruiscono la relazioni di fiducia che permettono agli utenti di sapere quale software gira sui server, con che modello economico e cosa viene fatto con i metadati. Cosa che gli utenti Signal non possono fare. -
@lorcon @ju premetto che parlo di XMPP solo perche lo conosco bene e perche non conosco gli altri sistemi federati di chat. La tua esperienza con XMPP (canonico Conversations su Android, Gajim o Dino su desktop, Converse.js su web) è cosi negativa?
Ormai da tempo dalle mie parti buona parte dei giri di movimento comunicano con quel protocollo senza troppa assistenza da parte degli hacklab locali.
Gli hacklab mettono su i server e costruiscono la relazioni di fiducia che permettono agli utenti di sapere quale software gira sui server, con che modello economico e cosa viene fatto con i metadati. Cosa che gli utenti Signal non possono fare.La mia esperienza? No, non è negativa. Ma la mia idea di comunicazione sicura va ben al di là dei "giri di movimento" (che mi interessano relativamente) e deve coinvolgere anche cerchie _molto_ più larghe per cui non ritengo, al momento, XMPP sostenibile e quindi preferibile a Signal. Poi ben venga che si diffonda e tutto ma preferisco concentrare le mie energie su altro. E in mezzo a questo altro ci metto sistemi di comunicazione che facciano direttamente a meno di internet, che è un collo di bottiglia tanto per Signal tanto per XMPP tanto per WA. Per cui le mie risorse preferisco metterle sul dire alle persone "usate Signal, consci dei limiti che ha" e nel lavorare per cercare di di tirare su sistemi autonomi a livello infrastrutturale. Ben vengano altri approcci perchè in questi temi la diversità è forza.
-
undefined muffa shared this topic
-
@ju tra l'altro non si tratta di "premiare Signal", si tratta di individuare il sistema più efficiente rispetto allo scopo che ci si da. Il mio scopo in questo momento è che quante più persone possibile siano in grado di comunicare con un sistema di IM in modo sicuro senza avere grandi capacità tecniche. Signal risponde a questa esigenza, le alternative proposte no. E aggiungo anche che siccome io sono dell'idea che i sistemi funzionanti debbano essere pagati consiglio pure di donare, io lo faccio su base mensile, a Signal in modo da garantire uno sviluppo continuativo e augurandomi che siano in grado di rendersi autonomi da sistemi di cloud.
sì che si tratta di "premiare Signal": lo scegli, lo diffondi, lo finanzi, quindi di fatto premi il modello che propone.
Detto questo, ovviamente, tu sai quali sono le tue esigenze e fai le tue scelte di conseguenza, sicuro si discute ma non son mica qui per farti cambiare idea o altro. 🙂
-
@ju e alla fine cosa si vince? Una bambolina? Non è un discorso di premi, non è un discorso di gara tra protocolli. È un discorso, per quanto mi riguarda, di che cosa è utile qui e ora in base alle mie esigenze
-
@ju e alla fine cosa si vince? Una bambolina? Non è un discorso di premi, non è un discorso di gara tra protocolli. È un discorso, per quanto mi riguarda, di che cosa è utile qui e ora in base alle mie esigenze
@lorcon@mastodon.bida.im "premi" nel senso che incentivi.
Incentivi l'uso di un certo modello, carichi la bilancia da una certa parte, dillo come ti pare e soprattutto, se non si fosse già capito: fai un po' come cazzo che ti pare. 😉
-
@Uilebheist @ju ma quindi come alternativa rimane solo XMPP? Perché so di qualcunə a cui non riesce a funzionare
@guardaminfaccia @Uilebheist @ju se hai voglia di provare a dire i problemi, magari sul fediverso troviamo che ci sono delle soluzioni?
ma se hai voglia
-
undefined filobus shared this topic
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@jonny "my French lover, le Chat GPT". Jesus Christ. She's coming in hot with the red flags, and the book I want is how to never meet her.
-
Roma: il “villaggio sportivo” dell’esercito al quarticciolo. “e’ propaganda militare mascherata da iniziativa sociale”
@anarchia
Martedì 21 ottobre, al Quarticciolo, quartiere della periferia est di Roma, verrà allestito un villaggio sportivo organizzato dall’Esercito Italiano presso la parrocchia Ascensione NSGC. L’iniziativa
-
the ghoulish hollowness of soul to even formulate the idea "i want to be the kind of person who has written a book about how to date me, but i don't want to write it, but i do want to sell it for $4.99"
-
RE: https://neuromatch.social/@jonny/115409736697961808
where is Hunter S. Thompson when you need a "The chatGPT girlboss dinner is decadent and depraved"
-
The Lambda Papers: When LISP Got Turned Into a Microprocessor
The physical layout of the SCHEME-78 LISP-based microprocessor by Steele and Sussman. (Source: ACM, Vol 23, Issue 11, 1980)
During the AI research boom of the 1970s, the LISP language – from LISt Processor – saw a major surge in use and development, including many dialects being developed. One of these dialects was Scheme, developed by [Guy L. Steele] and [Gerald Jay Sussman], who wrote a number of articles that were published by the Massachusetts Institute of Technology (MIT) AI Lab as part of the AI Memos. This subset, called the Lambda Papers, cover the ideas from both men about lambda calculus, its application with LISP and ultimately the 1980 paper on the design of a LISP-based microprocessor.Scheme is notable here because it influenced the development of what would be standardized in 1994 as Common Lisp, which is what can be called ‘modern Lisp’. The idea of creating dedicated LISP machines was not a new one, driven by the processing requirements of AI systems. The mismatch between the S-expressions of LISP and the typical way that assembly uses the CPUs of the era led to the development of CPUs with dedicated hardware support for LISP.
The design described by [Steele] and [Sussman] in their 1980 paper, as featured in the Communications of the ACM, features an instruction set architecture (ISA) that matches the LISP language more closely. As described, it is effectively a hardware-based LISP interpreter, implemented in a VLSI chip, called the SCHEME-78. By moving as much as possible into hardware, obviously performance is much improved. This is somewhat like how today’s AI boom is based around dedicated vector processors that excel at inference, unlike generic CPUs.
During the 1980s LISP machines began to integrate more and more hardware features, with the Symbolics and LMI systems featuring heavily. Later these systems also began to be marketed towards non-AI uses like 3D modelling and computer graphics. As however funding for AI research dried up and commodity hardware began to outpace specialized processors, so too did these systems vanish.
Top image: Symbolics 3620 and LMI Lambda Lisp machines (Credit: Jason Riedy)
-
@reiver provocative!
-
As a biologist, I have determined that shorebirds can be divided into 6 categories:
- Short bill long legs fren
- Fancy billed big bois
- Short billed round bois
- Short kings w big bills
- Long legged supermodels
- Silly-lookin' babies
-
When I die, I want my kids to get a dog and name him Dad.
