Live data from Hacker News

An off-grid social network

staltz.com

291–300 of 383 posts

Re: An off-grid social network

#291
post #275
post #244

Earlier quoted context omitted.

Can you (or someone) clarify the difference between Patchwork and SSB? Does SSB handle the networking and discovery and encryption and whatnot, and Patchwork just acts as front-end for displaying diaries, connecting to pubs, posting and so forth?

The downvotes on replies are baffling over here. Here's what AljoschaMeyer said, and it's all accurate: Patchwork is a user interface for displaying messages from the distributed database to the user, and to allow the user to add new messages. The underlying protocol supports arbitrary message types, patchwork exposes a UI for interacting with a subset of them. Anyone could write and use other UIs while still contrib…

Thank you, I enabled [dead] and I too am baffled at why useful responses are getting killed.

edit- they got unkilled.

Re: An off-grid social network

#292
post #39

Earlier quoted context omitted.

Then I have yet another device permanently plugged in and running, at a time where I and frankly all of us should try to reduce our energy consumption.

A Raspberry Pi is very low-powered though, it's completely insignificant compared to the power used by the webservices you use daily.

People don't want another thing to plug in even if it's low-power. IoT is still nascent and I already don't have enough outlets in my house...

Re: An off-grid social network

#293
post #286

"off the grid" and "social network" pick one.

Depends what you mean by "off the grid".

I've been working on something that has some similarities. Its a mesh network of pest traps in the New Zealand bush. Battery life is very important, so each node sleeps most of the time, then periodically wakes up and communicates with its neighbours. Made more complex by devices not having real time clocks.

Once every node in the network is powered down most of the time, I don't think you can consider it a grid.

Re: An off-grid social network

#294

As a historical note, there used to be quite a few very popular solutions for supporting early social networks over intermittent protocols. UUCP [ https://en.wikipedia.org/wiki/UUCP ] used the computers' modems to dial out to other computers, establishing temporary, point-to-point links between them. Each system in a UUCP network has a list of neighbor systems, with phone numbers, login names and passwords, etc. Fido…

Bang paths are still supported in email addresses too! Your email address might be george@cmu!vax!something!mitre!foo Which meant Route the email through foo->mitre->something->vax->cmu. Sysadmins would often keep tables of known routes. While people would describe their route from common known routing hosts. We were so living in the cyberpunk future then.

Computing was more fun back then.

Re: An off-grid social network

#295
post #279

Earlier quoted context omitted.

> Encryption alone does not make file-sharing a private affair. Someone who is "in" on encrypted content can observe the swarm anyway, thus gains very little from performing snooping on a DHT. On the other hand a passive DHT observer who is not "in" will be hampered by not knowing what content is shared, he only sees participation in opaque hashes. Additionally payload encryption adds deniability because anyone can t…

> Someone who is "in" on encrypted content can observe the swarm anyway, thus gains very little from performing snooping on a DHT. I can see that this thread is getting specific to Bittorrent, and away from DHTs in general. Regardless, I'm not sure if this is the case. Please correct me if I'm wrong: * If I can watch requests on even a single copy of a single key/value pair in the DHT, I can learn some of the IP addr…

> This does not strike me as "quite small," but that's semantics.

It is quite small because bittorrent needs to use some peer source. If you're not using the DHT you're using a tracker. The same information that can be obtained from the DHT can be obtained from trackers. So there's no novel information leakage introduced by the DHT.

That's why the DHT does not really pose a big information leak.

> This kind of proves my point. You're recommending that applications not rely on DHTs, but instead use their own content-specific gossip network.

That's not what I said. Relying on a DHT for some parts, such as bootstrap and discovery is still... well... relying on it, for things it is good at.

> But the point I'm trying to make is that they're not good for much else, and developers need to be aware of these limits if they want to use a DHT for anything.

Well yes, but these limits arise naturally anyway since A stores data for B on C and you can't really incentivize C to manage anything more than small bits of data.

> I can see that this thread is getting specific to Bittorrent

About DHTs in general, you can easily make reverse lookups difficult or impossible by hashing the keys (bittorrent doesn't because the inputs already are hashes), you can obfuscate lookups by making them somewhat off-target until they're close to the target and making data-lookups and maintenance lookups indistinguishable. You can further add plausible deniability by by replaying recently-seeing lookups when doing maintenance of nearby buckets.

Re: An off-grid social network

#296
post #82

No, you're not. If you were that would mean you would be interested. If you were interested you would have more to say. You're just trying to imply that I must suggest an alternative before commenting on the poor state of "social networks".

I'm incredibly interested. I imagined your parent comment was motivated by frustration that we share.

Seems that networks of a social nature are inherently a feed of news. News from here or there, from one friend or another, etc...

What else could it be?

Re: An off-grid social network

#297
post #282

Earlier quoted context omitted.

Currently, a user can simply post an `about` message in the stream. Clients will then automatically use this name instead of the key.

What happens if two users post an about message with the same name?

what happens "in real life" when two people go by the same name?

Scuttlebutt works the same way: anyone can name themselves anything and anyone can name other people anything, it's up to the client how to interpret those messages. more on how SSB embraces subjectivity: https://youtu.be/P5K18XssVBg.

Re: An off-grid social network

#298
post #146

Earlier quoted context omitted.

My impression was that keybase is distributed? Can it be used without talking to keybase's servers?

The Keybase server manages giving out usernames, and recording the proof URLs for users, and then your client hits the URLs, checks that the proofs are signed with the appropriate key, and caches them to watch for future discrepancies. Keybase offers decentralized trust, in that the Keybase server can't lie to you about someone's keys -- your Keybase client will trust their public proofs and not the Keybase server --…

Does keybase still upload the private PGP key to the keybase server by default? https://github.com/keybase/keybase-issues/issues/160

Re: An off-grid social network

#299
post #15

This sounds like what I wanted from GNU Social when I first joined over a year ago. GNU Social/Mastodon is a fun idea, but it falls apart when you realise that you still don't own your content and it's functionally impossible to switch nodes like it advertised, along with federation being a giant mess. I tried to switch what server my account was on halfway through my GNU Social life, and you just can't; all your fol…

I mean, my view on the switching nodes thing is. It's not like you can just switch emails. Sure you can install a shim in there to forward everything, but there is no way to actually switch it. And that is the design GNU social uses.

Re: An off-grid social network

#300

Earlier quoted context omitted.

The Keybase server manages giving out usernames, and recording the proof URLs for users, and then your client hits the URLs, checks that the proofs are signed with the appropriate key, and caches them to watch for future discrepancies. Keybase offers decentralized trust, in that the Keybase server can't lie to you about someone's keys -- your Keybase client will trust their public proofs and not the Keybase server --…

Does keybase still upload the private PGP key to the keybase server by default? https://github.com/keybase/keybase-issues/issues/160

We're trying to move away from PGP to a per-device key model (keys never leave the client devices): https://keybase.io/blog/keybase-new-key-model
Post reply on HN