wrote a good introductory post to some of the challenges of building apps, and how these differ between federated and P2P projects:
medium.com/@jaygraber/decentra

"Most behave like expensive, slow databases that sacrifice efficiency for immutability and global consensus. Blockchains are logically centralized, exerting great effort to make many untrustworthy computers behave like one computer. Even if next generation blockchains become much more scalable, they still seem ill-suited to store social media content which is mutable, ephemeral, and does not require global agreement on its state."
-

"... a downside I’ve observed in social networks where content is monetized is that user behavior becomes transparently driven by monetary incentives in ways that feel less genuine. This applies to influencer culture on Instagram as well, but cryptocurrency social networks bake it in from the start. This may be the inevitable result of replacing intrinsic with extrinsic motivations, or there may be an incentive structure that strikes the right balance that has not been achieved yet"
-

It seems to me that trying to monetize posts is solving the wrong problem. The only reason money needs to be involved in social network platforms is that servers have to be paid for. Get rid of servers with a pure network (even one with ) and money doesn't need to be involved at all. This seems to be working pretty well for and .

is a different story, at least when it comes to works like long form articles, music, or films, which take some work to produce and often require the creators to spend money to produce them. As Jay Graber says in her article, don't seem like the best solution for storing this sort of media, something like (or , or ), is probably a better way of distributing these. But using blockchains as a distributed monetization layer for them could work.

@strypey I've just been skimming your posts, looks like interesting stuff. Thanks for sharing. BTW, as you're mentioning IPFS and SSB, have you checked out dat? Just used it the other day to check out some cool cc-licensed original music. Felt gooood to use for many reasons. :)

@onymous when you say "dat", do you mean something like browser? The SSB protocol is based on , as are various other projects.

@strypey @onymous DAT is okay but it has a problem that bothers me: content data is mutable (because you can choose not to keep it, and replace it at the meta-data layer) but the meta-data layer at the top is not. so you slowly and forever accumulate garbage that has to be kept because the protocol demands it even though it points to content hashes that nobody has any longer.

SSB (secure scuttlebutt) seems okay but has a fatal flaw: it's based on some nodejs internals (order json keys get written) that are not part of the spec, even though they rely on hashes that need a deterministic order of keys and values. So the entire spec is mostly worthless and might as well say "implementation defined."

@icedquinn Intriguing, do you think or are better technical approaches than DAT in these respects?
@onymous

aether, ssb 

@strypey @onymous I have no familiarity with "DataShards."

Aether is a flood protocol with an expiration date attached. It is vaguely SSB except with a social contract to delete and not replicate any blocks older than six months. You also mint a proof of work when making a new block, then blast that block to anyone who will listen who in turn does the same. Upstream points out this is why there's no images; everyone has everything (even what they don't read) but a small network with plain text can deal with that. (He's now trying to sell a "pro" version based around hosting your own, btw, so it seems the answer to scaling is give him cash and run your own fedi.)

I have a couple of things for SSB:

They need to stop relying on Node's serialization order and putting signatures inline with the data. Put the JSON in an envelope (ex. dump it to an escaped string) and then sign the envelope. (cf. the Box APIs from NaCl, or sign and seal envelopes from MS.)

Some of the already solved XML crypto stuff does that too; encode the document to base64, put it in a cdata, sign the cdata, since crypto MUST BE 100% DETERMINISTIC and XML/Json documents are very much not.

ALL messages ought to be blobs, so the immutable chain is just an authenticated timeline of blobs and actions against them. That's how the prunable transactions work in NXT/Ardor and its how PNG files do work in SSB. But do it with everything. Cause then I don't have to archive messages that mean nothing to my hub or if some random EU law says i have to delete all messages that contain the letter J in them.

i have one more but it needs its own post

@strypey @icedquinn Hey, love following this conversation. I do not understand why people are using javascript at all, especially not around things that have anything to do with encryption. It's nice to read your critique of the implementations of the different ideas, even if some of it is over my head.

What I have to say though, and maybe this doesn't mean much from me who's been living under a rock since like forever, but the community in SSB is amazing. It's inspiring.

@onymous
> the community in SSB is amazing.

Funny, that's what people used to say about Titter, and before that IRC, and before that, old school BBS networks like . The common denominator is early adopters, it was said about each when they were small populations using relatively unknown platforms.

@icedquinn

@strypey
Yeah, I believe that's true. However, I guess that means they are doing something right when it comes to creating a new platform, successfully making it inviting. Without that something I'm not sure people would join it and stay active.

I guess I just wanted to say something nice about SSB even if I agree that the technical stuff isn't perfect.

@icedquinn

@onymous fair enough ;) I'll be more impressed if the community is still amazing if it manages to scale up to 100 or 1000 times its current user base. But you have raised an issue I've considered but never really discussed, that sometimes the choice of network software is more about the cross-section of people currently using it, than the particular features it has. It might be worth putting up with an inferior UI to connect with an amazing community ;)
@icedquinn

@onymous having said that, for me, is a much better UI than the vanilla web client Titter offers, so I'm here for that as well as the community ;)
@icedquinn

@strypey
I never understood Twitter, and while Mastodon makes me feel a lot better as a user (I guess I feel less violated) it makes me sick to my stomach as a sysadmin when trying to set it up and manage it. It's in may ways great stuff, but... jikes.

About the Twitter/Mastodon interfaces, unlike my impressions of SSB (or Patchwork, rather), these kind of interfaces feels like a hundred people shouting at the same time. I'll check out Pinafore, thanks! :)

@icedquinn

@onymous are you using the old 3-column Mastodon UI?

> a hundred people shouting at the same time

... is exactly how I'd describe that.

@strypey Nah. One-column. Not as bad as the multi-column one even if I like the like... sense of order with filters and stuff. Part of me likes the order but another part of me is just feeling overwhelmed.

Somebody on SSB described SSB as being part of "the slow web". I like that.

@onymous I think what you're noticing is the difference between a "social network" and "social media". One connects you to private communication from specific people you know, or people they know (). The other one hooks you up to a firehose of public posts from all sorts of people.

Follow

@onymous have you tried , a P2P app for text/ voice/ video chat? It's more like social networking than social media.

@strypey
No I haven't, I'll make sure to check it out. Thanks. :)

Sign in to participate in the conversation
Mastodon - NZOSS

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!