|author||bnewbold <email@example.com>||2013-02-03 14:50:09 -0500|
|committer||bnewbold <firstname.lastname@example.org>||2013-02-03 14:50:09 -0500|
Diffstat (limited to 'half-baked.page')
1 files changed, 57 insertions, 0 deletions
diff --git a/half-baked.page b/half-baked.page
index 2b7e7aa..096bf92 100644
@@ -62,3 +62,60 @@ interface, bus sniffing, peripheral emulation, kernel unit tests). High-density
pins to many different cable types (extra $$$) with logic-level shifters:
"universal digital I/O". $100.
+* similar to livejournal, reddit, slashdot
+* federated accounts (email@example.com) with petnames via contact list
+* RSS feeds of new topics started by individuals or for groups
+* no concept of "friending" built in, but do have ACL (can view, can comment)
+ based on contacts list
+* head of thread can be a canonical URI/URL of external content
+* abuse/downvote gets reported to thread-hosting domain
+* by default all user content is crypto-signed by default
+* policy is left to domain servers: moderation of new messages, retainment
+ length, max number of users in a given topic, etc
+* primary anti-spam: only display stuff signed by people in contact lists
+* need a URI scheme for discussion threads
+* oauth? kerberos-like?
+* domain keys used to vouch for messages and users
+* integrated or parallel keyserver stuff?
+* cross-domain karma and spamlist sharing?
+* built-in GPG encryption, keyring
+* notification via XMPP?
+* crypto can happen either on server or by the client?
+* "profiles" are a seperate issue (webfinger?)
+* status updates could go through this, or XMPP or status.net?
+* TODO: salmon?
+* would need to specify:
+* storyboard of how a post/conversation would go
+* message formats
+* protocols between user-server and server-server
+* ascillary technologies: authentication, notification, encryption, contact
+* interop: HTTP website
+* "reliable asynchronous user-specific messaging"
+* same store-and-forward paradigm; same IMAP-like message archive paradigm
+* every core message signed by user and domain; unsigned messages get dropped
+* core message headers can be pseudo-shadowed/re-written by extention headers
+* user signing can be delegated to domain
+* domain maintains public keyserver for all hosted users
+* forwarded messages (mailing lists) signed by forwarding domain
+* users or domains can brand a user or domain as spam/abusive
+* domains maintain a web of trust/karma using announcements, refuse messages
+ from blacklisted users/domains
+* special abuse@, admin@ "out of band" addresses for resolving blocklist
+ issues, not blocked except for severe cases
+* attachments signed seperately, referenced by core message
+* standardize (via defaults) on compressed UTF-8 message body
+ optional safe-subset of HTML
+* hook into system-wide cacert/web-of-trust; individual user agents can specify
+ fallback policy