mirror of
https://github.com/flancian/garden.git
synced 2026-08-07 23:16:21 +00:00
176 lines
7.5 KiB
Markdown
176 lines
7.5 KiB
Markdown
- an instance of [[distributed press]]
|
|
- [[2021 05 19]]
|
|
- [[benedict lau]]
|
|
- [[hypha]]
|
|
- interested in building a tool that publishes through many different protocols
|
|
- sharing social messages seamlessly
|
|
- [[flancian]]
|
|
- [[paul frazee]]
|
|
- [[secure scuttlebut]]
|
|
- [[beaker browser]]
|
|
- [[hypercore protocol]]
|
|
- [[ctzn]]
|
|
- [[guo]]
|
|
- matters.news
|
|
- serving mostly chinese communities
|
|
- looking at [[ipfs]], [[hypercore]]
|
|
- working on a protocol similar to [[unwalled garden]], but also thinking of integrating [[rss]]
|
|
- also interested on [[webmentions]]
|
|
- [[vera]]
|
|
- working on [[agora]]
|
|
- background in distributed social systems, worked on (sp?) status, before mastodon
|
|
- [[fauno]]
|
|
- (mic incoming) :)
|
|
- [[paul frazee]]
|
|
- [[distributed vs federated]]
|
|
- a bit stuck here currently
|
|
- the way to conceptualize
|
|
- [[federated]] ~ [[mastodon]]
|
|
- [[distributed]] ~ [[ipfs]] mesh
|
|
- completely open system, if you're in the mesh you're in
|
|
- technologically, user experience wise is great
|
|
- trying to figure out how to deal with the [[cost]] structure
|
|
- in the case of social media, you're making your own twitter
|
|
- how do you get economies of scale worked in there?
|
|
- [[filecoin]]?
|
|
- [[gateway model]]
|
|
- ipfs gateway: there is more than one of them
|
|
- if your mesh contains social data, you get a social network
|
|
- [[ben]] what are the costs involved?
|
|
- [[paul]] unsure but they all seem associated to a side business so far
|
|
- advantages
|
|
- ?
|
|
- serverless clients are possible
|
|
- [[ben]]
|
|
- less well maintained gateways become issues for user experience
|
|
- censorship
|
|
- [[guo]] yes, gateways become a centralized point
|
|
- gateway should be a backup after serverless client
|
|
- [[paul frazee]]
|
|
- spent 6-8 months working on a social network back in [[beaker]]
|
|
- some stuff that stops you:
|
|
- links that are a new protocol are an issue
|
|
- ux killer on stuff like twitter
|
|
- didn't have a push messaging system back then
|
|
- didn't want to have to deal with spam
|
|
- ux killer: no notifications unless mutual follow
|
|
- [[aggregator]]
|
|
- try to bring in positive properties of the system
|
|
- [[flancian]]
|
|
- [[metcalfe's law]]
|
|
- [[ben]]
|
|
- [[web mentions]]
|
|
- [[guo]]
|
|
- content feed + social graph as a distributed publication and social network
|
|
- people can store their content feed and social graph anywhere
|
|
- user control their data
|
|
- search
|
|
- separating storage and aggregation
|
|
- [[paul frazee]]
|
|
- database vs datamesh
|
|
- federation puts application logic in the wire protocol
|
|
- [[flancian]]
|
|
- [[datamesh]] should probably be treated as a commons
|
|
- [[guo]]
|
|
- we could avoid many governance issues at the [[database]] layer
|
|
- [[ben]] this sounds like the [[scuttlebutt]] and [[hypercore model]]?
|
|
- [[paul]] when last involved there was no global entrypoint, it was [[gossip protocol]]
|
|
- [[pubs]] were [[store and forward relays]]
|
|
- information would flow 100% on the basis of the social graph
|
|
- led to complexities; people could give you keys and still be unreachable
|
|
- [[flancian]]
|
|
- [[paul]]
|
|
- how do you end up in a situation in which governance is required?
|
|
- [[guo]]
|
|
- datamesh seems like it does not require governance, but the aggregator does
|
|
- (interlay vs overlay?)
|
|
- [[ben]] aether (sp?)
|
|
- distributed reddit
|
|
- distributed moderation
|
|
- liquid democracy-like
|
|
- [[ben]]
|
|
- we need to agree on:
|
|
- schemas
|
|
- distribution protocol
|
|
- aggregator censorship
|
|
- what happens when your computer ends up hosting hate speech?
|
|
- you can stop the flow in the mesh and that applies negative evolutionary pressure
|
|
- [[paul]] aether does [[default allow]], I do [[default deny]]
|
|
- [[flancian]]
|
|
- minimum exchange format
|
|
- [[guo]]
|
|
- choice of markdown vs html
|
|
- chose html over markdown, it supports arbitrary media
|
|
- [[encryption]]
|
|
- exclusive content
|
|
- hard to define protocol-level encryption standard
|
|
- bake the encryption message into the html
|
|
- [[mdx]]
|
|
- [[ben]] decided to first publish/store things as html
|
|
- most people want to have something ready-to-publish
|
|
- but a consumption pattern arises: you copy/paste whole articles
|
|
- on the dweb there is an opportunity for this as we can publish different formats of the same concept
|
|
- get content in more than one format
|
|
- [[paul]]
|
|
- [[schemas]] in general
|
|
- I would describe what you were discussing as "rich text format"
|
|
- orthogonal to schemas
|
|
- fighting with schemas since [[secure scuttlebutt]]
|
|
- pissed off [[rdf]] people
|
|
- reached https://ctzn.network/comment
|
|
- scuttlebutt: did not impose *any* schema obligations; disastrous approach
|
|
- [[unwalled gardens]]: enforced types
|
|
- [[ctzn network]]: urls identifying the schemas with a machine readable format
|
|
- rejects messages that don't comply with the schema
|
|
- believe in this approach
|
|
- if you don't, you end up in the tragedy of the commons or failure in collective action (scuttlebutt)
|
|
- compatibility with the schema dictates everything you can do
|
|
- you have a feature, you add a dependency
|
|
- had a post type
|
|
- would be nice if you have a topic
|
|
- if you are not subscribed to [[cats]], you won't see it
|
|
- but you can't rely on it as many clients won't support it
|
|
- you might end up spamming old clients
|
|
- [[fatal ambiguity]]
|
|
- once you see this, schemas start seeming risky to change
|
|
- you can do extension points, but would suggest against
|
|
- current approach:
|
|
- well defined schemas
|
|
- people can determine their own schemas
|
|
- control the [[ctzn network]] schemas
|
|
- can have extension tables
|
|
- [[ben]]
|
|
- feel like [[scuttlebutt]] has a schema, otherwise you couldn't have more than one client
|
|
- what it lacked, it seems, is versioning?
|
|
- how do you manage upgrades?
|
|
- [[paul]] the problem is multiple clients controlled by different devs
|
|
- [[flancian]] what do you really need for features -- usually you'd want to have the minimum minimum schema requirements?
|
|
- [[paul frazee]]
|
|
- [[web mentions]]: exploring now
|
|
- [[unwalled garden]]
|
|
- difference between it and [[ctzn network]]
|
|
- suppose you want to have the ability to have mentions in your comments
|
|
- you have to keep parsing for entities if you store text or text-like
|
|
- using [[hyperbee]] in [[ctzn]]
|
|
- it can list directories or keyspaces in order
|
|
- more like a database technology
|
|
- for distributed press/unwalled garden: file oriented approach can work over http
|
|
- [[guo]] in the comments problem, who owns the post data?
|
|
- the post it's on could 'own' it
|
|
- the [[comment]] writer could own it
|
|
- this seems safer?
|
|
- [[fauno]]
|
|
- if we allow for comments, who is responsible for keeping them? hateful comments/censorship/etc
|
|
- [[webmentions]]: fascist websites pinging you
|
|
- people don't have time to moderate
|
|
- [[ben]] same thing is seen in wordpress
|
|
- [[fauno]] web mentions and how to keep bad parties out
|
|
- [[flancian]] how will moderation work in [[ctzn network]]?
|
|
- [[paul]] would like to have a great answer :)
|
|
- [[reputation systems]]
|
|
- no one size fits all
|
|
- this lets you scale the work
|
|
- reputational graph approach
|
|
- [[subjective moderation]]
|
|
- elected moderators
|