: 85type ( addr u -- )
    bounds ?DO  I I' over - 4 umin cells .base85s + perform  4 +LOOP ;

: b85digit ( char -- n ) $7F umin chars>85 + c@
    dup $FF = !!no-85-digit!! ;

: base85>n ( addr u -- n )  0 1 2swap bounds +DO
	I c@ b85digit over * under+ 85 *
    LOOP  drop ;
: (base85>$) ( addr u -- addr' u' )  bounds ?DO
	I I' over - 5 umin dup >r base85>n { | w^ x } x le-l! x r> 4 5 */ type
    5 +LOOP ;
: base85>$ ( addr u -- addr' u' ) ['] (base85>$) $tmp ;

: 85" ( "base85string" -- addr u )

	net2o:max-flyburst
    THEN rate( cr ) ;

\ acknowledge

$20 Value mask-bits#
: >mask0 ( addr mask -- addr' mask' )
    BEGIN  dup 1 and 0= WHILE  1 rshift maxdata under+  dup 0= UNTIL  THEN ;
: >legit-back ( addr mask -- addr' mask' )
    data-map .mapc:dest-back >r
    over r@ [ maxdata $20 * ]L umax [ maxdata $20 * ]L  - u<
    IF  r> 2drop 0  EXIT  THEN
    over r@ u< IF  r@ rot - addr>bits rshift r> swap  EXIT  THEN
    rdrop ;
: >legit-head ( addr mask -- addr' mask' )

# Using net2o as social network #

When Google+ shut down, I took the opportunity to accelerate my plans on
running social networks over net2o.  How does a social network over a
peer2peer network look like and what's the challenge?

## Data structure of social network postings ##

* Timelines (of collections and groups) are kept as chat logs.  Each posting
  is a chat log entry, which contains a short teaser of the posting, possibly
  a thumbnail image, and a link to a DVCS project.
* A thread (posting+comments) is a DVCS project.  That by itself is another
  chat log, with each checkin as log entry.  Checkins contain a reference to a
  file that highlights the posting/comment added in the checkin.  Likes are
  just messages with a like emoji and a reference to the checkin that is
  liked.  The DVCS as base to organize a thread allows editing.  It's even
  possible to collaboratively edit if permissions allow.
* Checkins can be pull–request style, then they need interaction from the
  owner.  Normally, however, you'd want to have them automatically checked
  against permissions and conflicts and pulled when they fit.
* A posting itself is a markdown file.  Images and videos are in jpeg/png and
  mkv format.
* Likes/dislikes and votes are short messages containing only an emoji code.
  Permission to send these short messages is limited to make sure you can only
  like once, so you need to face out your previous like if you want to send a
  new one.  Votes can be closed, so the call for vote shall have a deadline.

## Importing data from other networks ##

One thing that is annoying with new networks is that they start all empty.
You leave all your postings behind in the old network.  But the GDPR allows to
take out data, and if everything is fine, it's possible to convert that data.

I wrote an importer for Google+, which is mostly complete by now, and also
started with Blogger.com, Twitter, and Facebook importers.  Other importers
will follow.

Twitter’s takeout is very limited, it only contains your own tweets, no
answers to your tweets from others, so it takes the communication part out of
the takeout.  Tweets you answered to are referred, so you can use Twitter’s
API to access them, you can probably also search for answers to a particular
tweet and get those.

## Connecting to other social networks ##

While in general, a connector to a plattform is a bad idea, for social
networks, where publicity matters, connectors can have some place, at least
for the transition period.  Though I have not attempted to actually write one;
but at least for networks that have an API, you could import feeds into
net2o, and (with severe limitations) crosspost from net2o.

## Permissions ##

Social networks require a more fine–grained permission system than mere
chats.  Who’s allowed to write, to read, and to delete what?  In a chat,
participants are allowed to read, write, and delete their own messages.  In a
social network, we can have wider ranges of permissions.

Groups can have all members create new postings, and Wikis allow all members
to edit postings.  Moderators can change state, like protect an entry and
resort to manual handling of pull requests if an edit war is going on, or they
can move members to read–only status.  Comments for a particular posting can
be disabled, if the discussion gets out of control.  And of course, as a basic
measure already necessary for chats, people can be kicked out or denied
anything but read access.

Moderating quality depends on the interface.  If the moderator interface is
cumbersome, people don’t want to moderate, and the mud from a bad discussion
causes problems.  Moderation can also happen under alternative IDs, so
normally, you don't use your moderator ID when discussing, only for
moderating.  The interface shall facilitate that.

Write permissions are performed at automatic pulls.  Someone sends you a
message, you fetch the patch set that is associated, and if it fits, you merge
it.  Since chats are connected by a mesh, everybody checks for write
permission, and forwards if they think it’s ok.  Under strict moderation
guidelines, you might want to have a moderator approval signature before you
make those messages visible.  Moderators can reply to a commit with an “👌”
emoji, without that, it‘s not processed.

Read access is much more critical: This needs to be protected by encryption.
Such encryption is already available for private/protected chats, so use
that.  You can also use encryption for shadow–bans: Here, the “👌” reply is
only encrypted for the shadow—banned person or group, and the others will not
see it.

## Circle sharing ##

Google+ in the beginning had a good way to facilitate quick growth of peers:
circle sharing.  You can recommend a group of people you find worthwile to
listen to to other people.  Google+ disabled that function later, increasing
the ghost town problem.  If you think about permissions, circle sharing should
also work for blocklist sharing: If people already know who's best blocked,
and they can share their lists, bad actors (spammers and trolls) have more
trouble getting through.

Circle sharing can be implicitly also offered when you have groups: Once you
know the members, you have such a circle.  However, people just lurking in a
group may not have their identity exposed.  Hidden readers are problematic in
private groups, but they are not problematic in public groups where hidden
readers can be the vast majority.

## Meta–information ##

An ID needs meta information, what kind of collections and groups it has, and
that needs to be a chatlog under a well-known name.  After contacting an ID,
you fetch that and off you go.  This meta information already needs
permissions, e.g. deny read access for private collections and groups — that
is done through encryption.