[OT] decentralized "cloud" storage - Opinions

[Soviet_Mario]

while starting some research about IPFS (interplanetary file
system)
I've come across this "project"

https://wildland.io/

Does anybody ever heard of ?
If so, what do you think of it ?

Is it a "trustless" (= no trust needed at all) storage ?

I'm reading that, while decentralized cloud encrypt and
split files and store chunks over PCs elsewhere (I still
have to figure out which of the many connected to the net is
"eligible" to store : my only previous experience was the
SEEDING in bittorrent, which seemed rather unreliable since
once one has had enough, they simply stop seeding and parts
of files may become unavailable).
But it seems that some central server (to balance the load,
to assign bandwidths, track the hashes, assign storage
quotas to nodes ... maybe determine if they warrant what
they promise by some bonus/malus mechanism) is still needed.

If that is true, it is not entirely decentralized and
"unstoppable" system.

What do you think of this ?

Any site to get better documented ?

TNX



--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[Fonntuggnio]

[Soviet_Mario]

On 26/06/22 15:58, Soviet_Mario wrote:
> while starting some research about IPFS (interplanetary file
> system)
> I've come across this "project"
>
> https://wildland.io/
>
> Does anybody ever heard of ?
> If so, what do you think of it ?
>
> Is it a "trustless" (= no trust needed at all) storage ?
>
> I'm reading that, while decentralized cloud encrypt and
> split files and store chunks over PCs elsewhere (I still
> have to figure out which of the many connected to the net is
> "eligible" to store : my only previous experience was the
> SEEDING in bittorrent, which seemed rather unreliable since
> once one has had enough, they simply stop seeding and parts
> of files may become unavailable).
> But it seems that some central server (to balance the load,
> to assign bandwidths, track the hashes, assign storage
> quotas to nodes ... maybe determine if they warrant what
> they promise by some bonus/malus mechanism) is still needed.
>
> If that is true, it is not entirely decentralized and
> "unstoppable" system.
>
> What do you think of this ?
>
> Any site to get better documented ?
>
> TNX
>
>
>

SORRY for double posting ... Thunderbird is having problems
in posting, so I tried a "workaround" ... I had thought the
original post hadn't been deployed successfully :\ :\

[Soviet_Mario]

On 26/06/22 15:58, Soviet_Mario wrote:

> while starting some research about IPFS (interplanetary file
> system)
> I've come across this "project"
>
> https://wildland.io/
>
> Does anybody ever heard of ?
> If so, what do you think of it ?
>
> Is it a "trustless" (= no trust needed at all) storage ?
>
> I'm reading that, while decentralized cloud encrypt and
> split files and store chunks over PCs elsewhere (I still
> have to figure out which of the many connected to the net is
> "eligible" to store : my only previous experience was the
> SEEDING in bittorrent, which seemed rather unreliable since
> once one has had enough, they simply stop seeding and parts
> of files may become unavailable).
> But it seems that some central server (to balance the load,
> to assign bandwidths, track the hashes, assign storage
> quotas to nodes ... maybe determine if they warrant what
> they promise by some bonus/malus mechanism) is still needed.
>
> If that is true, it is not entirely decentralized and
> "unstoppable" system.
>
> What do you think of this ?
>
> Any site to get better documented ?
>
> TNX
>
>
>

SORRY for double posting ... Thunderbird is having problems
in posting, so I tried a "workaround" ... I had thought the
original post hadn't been deployed successfully :\ :\

[Paul]

On 6/26/2022 10:10 AM, Soviet_Mario wrote:

> SORRY for double posting ... Thunderbird is having problems in posting,
> so I tried a "workaround" ... I had thought the original post hadn't been deployed successfully :\ :\

The posting sequence to Eternal-September is accepting posts,
without sending a status back to the client that the post succeeded.

This makes the user think the posting was not sent.

When it was.

A workaround is to use another server for posting,
until the issue is resolved.

Paul

[bad sector]

anything stored in a 'cloud' is one step
short of a streaming youtube colonoscopy

my 2

[Soviet_Mario]

sorry I don't very much master humour in English :\
I'm not sure I've understood it right

I cannot figure out what a youtube colonoscopy is supposed
to be ....


>
> my 2

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

["Followup-To:" header set to alt.os.linux.]

Soviet_Mario wrote:
> while starting some research about IPFS (interplanetary file
> system)
> I've come across this "project"
>
> https://wildland.io/
>
> Does anybody ever heard of ?

I haven't; until today.

> If so, what do you think of it ?

Sounds like it's trying to be dropbox/g-drive/b2/etc ... but
"centaralized"

>
> Is it a "trustless" (= no trust needed at all) storage ?

Doesn't sound like.

> [...]

> But it seems that some central server (to balance the load,
> to assign bandwidths, track the hashes, assign storage
> quotas to nodes ... maybe determine if they warrant what
> they promise by some bonus/malus mechanism) is still needed.

"your" PC presumably becomes that "central server(tm)".

> [...]

> Any site to get better documented ?

Their "Documentation" link seems pretty alright -- but I haven't read it
in depth.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmK5e/AACgkQbWVw5Uzn
KGDFow//Qg/HFJ6gwYHW56XH9dsIIu2g23NKfzRXqcbst3gycsoYTmQ68nbWfBDl
V9/IYiEOL7YZMHS4F0aGjL5gn7SILlsN99y3wsDywqAOIXA2TbGrWOwc602cAFiB
7l+8Z3nDQHIVLsHojehfjeWPpejRgBfsATuK/pB5Pv7YpdfImeqKL995f+NCkHHi
bFS7m8O9jUsqPSpDGN5tQHtkKIIRPRsDbCsZmsnayenzNK1CbaRaYRVa4Q4ioQht
HztMgfegBfPdXlomKKYwrl+OP+pxvt+g5saLTXoRF1wVtcKcM12d8JA92Xip9b96
t/c9/KMA9kwlLUE0n28J+GHgelNdXNY6Axa9BavGb56HCzRRAVtZeQbM1ebBPjVL
NRw8n+zKQC5+hk+q+yR7y6nO86lxteNmGt7uNnqMesYzpRmyMmDGpx4zCbKK0g71
0XBLbe0yxfsNqnvniDjToFthDDW4F3tGa1Kgb0l6cjZOQS83QTXt9IubLz74XRbw
lQDUGWlHTtslNQlfcQpr89Z2Zf5teyxJOi7p+eWUcsVbazfdLsz5QU0q45tbGFvi
lbRl4w5RJaSpV8IHS2JQZhdHJX+laFsqe+jIQ0b1jBvHLxfcr45WhoJvxvYxxPAZ
xNRz3OhzGKx1eJZ6nZWTKWf/pUHDGJEomwK6+lxPefDujkIR/x4=
=Yi42
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

[bad sector]

Your _colonscopia_ streaming 7/24 to youtube or other
portal, can you imagine a more invasive violation of
your privacy? And please, spare me all the security
mantras, there isn't a single encryption block that
doesn't have a back door on every wall :-)))
The instant when 'cloud' was invented it was clear
why it was invented.


--
Oh Lord of the Keyrings on high, have I got bad news
for you: the word trust is nowhere to be found in my
security dictionary.

[Andrei Z.]

Soviet_Mario wrote:
> while starting some research about IPFS (interplanetary file system)
> I've come across this "project"
>
> https://wildland.io/
>
> Does anybody ever heard of ?
> If so, what do you think of it ?
>

Group members · Wildland · GitLab
https://gitlab.com/groups/wildland/-/group_members

Joanna Rutkowska - Wikipedia
https://en.wikipedia.org/wiki/Joanna_Rutkowska

Shrug. Time will tell.

[jrg]

er, this isn't eternal sept, is it? thought it was aioe...

[jrg]

On 6/26/22 14:21, bad sector wrote:
> anything stored in a 'cloud' is one step
> short of a streaming youtube colonoscopy

+1

[Mike Easter]

jrg wrote:

You are aioe. SM is e-s, as is Paul in this thread.

--
Mike Easter

[Soviet_Mario]

tnx, I'm gonna have a look

[25B.Z969]

Ooooh - insures data integrity/privacy/101-other-things ...

So THEY say.

If you use it, be sure to PRE-encrypt yer data before it
goes to their servers :-)

[Soviet_Mario]

sure, when relevant, end-to-end encryption would be safe.

[user one]

On 14/08/2022 16:03, Soviet_Mario wrote:
>
>
> sure, when relevant, end-to-end encryption would be safe.
>
>

What is "end-to-end encryption"? You only need your own data to be
encrypted. How did "end-to-end encryption" came into this topic?

[Soviet_Mario]

you have to pass the key to some other legit user to
decipher the transmitted data, I meant

[Killadebug]

On Mon, 15 Aug 2022 00:41:55 +0200, Soviet_Mario wrote:

> On 14/08/22 21:00, user one wrote:
>> On 14/08/2022 16:03, Soviet_Mario wrote:
>> >
>> >
>> > sure, when relevant, end-to-end encryption would be safe.
>> >
>> >
>> What is "end-to-end encryption"? You only need your own data to be
>> encrypted. How did "end-to-end encryption" came into this topic?
>>
>>
>>
>>
> you have to pass the key to some other legit user to decipher the
> transmitted data, I meant

I use Mega for my cloud storage. They offer "end to end encryption", here
is their definition of "end to end encryption" and how they implement it.
I've been using their service since 2017 and I have never had an issue.
They are very upfront, if you lose/forget your password and do not have a
backup copy of your recovery key, your data is toast, gone, kaput.

#quote#

How does MEGA’s end-to-end encryption work?

MEGA implements true end-to-end encryption for the entirety of its
service. No feature-limited “crypto folders”, no shortcuts, no
compromise, even where it hurts: The unfortunate users who lost their
password and forgot to back up their recovery key can attest to that.

It follows orthodox design principles:

All encryption and decryption takes place on the user’s devices.
Cryptographic keys never leave the user’s devices unless the user
actively exports a file, folder or chat link.

Coverage
The following data held in a MEGA account is end-to-end encrypted:

File and folder names
File fingerprints
File data
Thumbnail and preview images
Chat messages
Audio/video call media streams

Key Hierarchy

Everything starts with the user’s password.

The password decrypts the account’s master key (a.k.a. Recovery Key).

The master key decrypts the account’s RSA private key as well as all file
and chat keys.

The file and chat keys decrypt their respective files/attributes and
chats.

Note that all encrypted keys are stored on MEGA’s servers. The password
is not. Therefore, no keys can be decrypted as long as the password,
which is never sent to MEGA, isn’t known.

The master, RSA, file and chat keys are all generated using
cryptographically strong pseudo-random number generators.

For more information, see our security whitepaper: https://mega.nz/
SecurityWhitepaper.pdf

# end quote #

[Andrei Z.]

Sneakernet - Wikipedia
https://en.wikipedia.org/wiki/Sneakernet

ADPS - Amateur Digital Post Service
https://adps-project.org/documentation.html

:)

[Richard Kettlewell]

Killadebug <killa...@mouse-potato.com> writes:
> I use Mega for my cloud storage. They offer "end to end encryption", here
> is their definition of "end to end encryption" and how they implement it.
> I've been using their service since 2017 and I have never had an issue.
> They are very upfront, if you lose/forget your password and do not have a
> backup copy of your recovery key, your data is toast, gone, kaput.

You might want to have a look at https://mega-awry.io/.

--
https://www.greenend.org.uk/rjk/

[Soviet_Mario]

On 15/08/22 01:22, Killadebug wrote:
> On Mon, 15 Aug 2022 00:41:55 +0200, Soviet_Mario wrote:
>
>> On 14/08/22 21:00, user one wrote:
>>> On 14/08/2022 16:03, Soviet_Mario wrote:
>>> >
>>> >
>>> > sure, when relevant, end-to-end encryption would be safe.
>>> >
>>> >
>>> What is "end-to-end encryption"? You only need your own data to be
>>> encrypted. How did "end-to-end encryption" came into this topic?
>>>
>>>
>>>
>>>
>> you have to pass the key to some other legit user to decipher the
>> transmitted data, I meant
>
> I use Mega for my cloud storage. They offer "end to end encryption", here

yes, also SIGNAL and DISCORD use it, if I'm not wrong.

[Killadebug]

Excellent article. Thanl you for posting the link. It appears Mega has
acknowledged the issues and has corrected 3 out of the 5 listed. I use
their Linux desktop app, and receive regular updates to it.

Again thankyou for the link



--
Pull my finger

[Soviet_Mario]

But this linux app, which features has ?

I mean, it keeps local copies of files or just in the cloud
(like pCloud) ?
If you connect more devices (if possible), does it do
automatic syncing among them (Dropbox does, and has a really
amazing features : when both local copies are newer than the
last committed version, it automatically creates degenerated
versions called "copy in conflict", sort of bidirectional
updating).

I hate clouds that do not keep a true, complete, local copy
for fast use. pCloud keeps only a cache, and since the
connection is slow, is almost unusable locally

[Killadebug]

The linux app keeps local files sync'd to the Mega servers ( the cloud).
I've set it up to only sync specific folders, thunderbird, pan,
Downloads, etc. Anytime a local file changes the linux app immediately
syncs the file to their servers. If I delete a sync's file or folder
locally, it is immediately deleted from their server.

What I really like about their linux app is I check my email and it
sync's, then I do an update or something else and I need to roll back my
system from a previous btrfs snapshot using time since, say one from 3
hours earlier. When I do that and reboot into the restored snapshot, the
megasu-ync app immediately syncs the files from the cloud to my local
machine and thunderbired is just like it was before the snapshot rollback.

No megasync does not us a local cache file like pcloud, it sync's all
selected folders/files in the sync folder/file section of the app, in
realtime. I tried pcloud, but dropped it because of the sync file issue,
I have approximately 67 Gig worth of data I'm syncing, with pcloud that
would be an additional 67 Gig cache, Mega allows me to have a realtime
syncing which I think is more efficient use of space.



--
Pull my finger

[Soviet_Mario]

not really true (I am a 2 TB paid user of pCloud), the
amount of cache used is up to your choice (I devoted 10 GB
for instance), but pCloud caching is not really useful to
work in remote. It does not hold any actual DATA, it just
keeps headers (some descriptors used by the app to indicize
the data). Their use is just to allow a loop device to mount
a virtual partition very fast at startup and to give the
illusion to manipulate a local disk (which is not). There is
no data in it, essentially.
Time ago I made a small SW to copy files from pCloud virtual
partition to a local partition in gambas, tracking the
transfer times ... a slaughter : the bottleneck was the slow
connection.

anyway, I might have understood that Mega App is not smart
enough to manage access conflicts (not any single version
newer than the reference stored remotely), which implies to
work very tidely and orderly when accessing from more
devices at a time.
I happen to forgive this, and so I risk to unwittingly lose
some files :\

> Mega allows me to have a realtime
> syncing which I think is more efficient use of space.

sure ... but you evidently have an efficient internet
connection. I just have a mobile 150 GB/month connection,
also very slow and unstable.

[Killadebug]

One other feature Mega has is called file versioning. When a copy of the
file changes locally mega will not overwrite the exisiting file on the
servers, but place the updated copy there also. You can then go back and
restore an earlier copy of a file if you want.

I turned that off.



--
Pull my finger

[Soviet_Mario]

On 18/08/22 04:08, Killadebug wrote:
> On Wed, 17 Aug 2022 17:01:01 +0200, Soviet_Mario wrote:
>
>> On 17/08/22 02:47, Killadebug wrote:
>>> On Tue, 16 Aug 2022 15:40:29 +0200, Soviet_Mario wrote:
>>>
>>>> On 16/08/22 02:56, Killadebug wrote:
>>>>> On Mon, 15 Aug 2022 08:37:32 +0100, Richard Kettlewell wrote:
>>>>>

SNIP

>> :\
>>
>>
>>> Mega allows me to have a realtime syncing which I think is more
>>> efficient use of space.
>>
>> sure ... but you evidently have an efficient internet connection. I just
>> have a mobile 150 GB/month connection, also very slow and unstable.
>
> One other feature Mega has is called file versioning. When a copy of the
> file changes locally mega will not overwrite the exisiting file on the
> servers, but place the updated copy there also. You can then go back and
> restore an earlier copy of a file if you want.
>
> I turned that off.

mmmm, that sounds really intresting ! A personal git-hub ! :o

[Soviet_Mario]

On 18/08/22 04:08, Killadebug wrote:

> On Wed, 17 Aug 2022 17:01:01 +0200, Soviet_Mario wrote:
>
>> On 17/08/22 02:47, Killadebug wrote:
>>> On Tue, 16 Aug 2022 15:40:29 +0200, Soviet_Mario wrote:
>>>
>>>> On 16/08/22 02:56, Killadebug wrote:
>>>>> On Mon, 15 Aug 2022 08:37:32 +0100, Richard Kettlewell wrote:
>>>>>
>>>>>> Killadebug <killa...@mouse-potato.com> writes:

re-snip

>>
>>> Mega allows me to have a realtime syncing which I think is more
>>> efficient use of space.
>>
>> sure ... but you evidently have an efficient internet connection. I just
>> have a mobile 150 GB/month connection, also very slow and unstable.
>
> One other feature Mega has is called file versioning. When a copy of the
> file changes locally mega will not overwrite the exisiting file on the
> servers, but place the updated copy there also. You can then go back and
> restore an earlier copy of a file if you want.
>

Uhm, now I can recall of another tricky feature that made me
flee away many years ago (dunno if it is STILL a drawback),
which was : THE FILES NOT BEING USED (edited, downloaded)
for more than six months, would be simply deleted.
I discovered the thing after having just transferred sth
(with mainly backup purpose) and was horrified and ran away.

Do you know if NON PAID accounts still suffer from this
awful feature or it has been removed ?

> I turned that off.
>
>
>


--

[Soviet_Mario]

I found this answer
https://answerstoquestionpage.com/qa/does-mega-delete-files-after-several-months-of-inactivity.html

It seems that the automatic deletion is not performed on a
per-file basis, but basing upon whole account activity.
Just six months of inactivity is considered enough to delete it.
I'll definitely give it a miss, I tend to be rather untidy
with date/times and terms of such kind !
Brrrrrr, tremendous