Fossil

Check-in [f85bc326]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Several improvements to the new forum.wiki document
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: f85bc32619e9a34ffa0ff5abfe5881a452c8c56da0a267092db7831dfa520445
User & Date: wyoung 2018-08-08 18:52:14.670
Context
2018-08-08
18:55
Link fix in previous ... (check-in: be74f259 user: wyoung tags: trunk)
18:52
Several improvements to the new forum.wiki document ... (check-in: f85bc326 user: wyoung tags: trunk)
18:32
Typo fix ... (check-in: 15b20343 user: wyoung tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/forum.wiki.
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

  *  Third-party discussion forum and mailing list software tends to be
     difficult to install, set up, and administer.  Fossil Forums aim to
     be as close to zero-configuration as is practical.

  *  Posts are stored in the Fossil repository using the same
     [./fileformat.wiki | block chain technology] that Fossil uses to
     store your check-ins, wiki documents, etc. Posts sync to clone
     repositories in a tamper-proof fashion.

  *  Because of Fossil's [./delta_format.wiki | delta compression
     technology], discussions add little space to the size of a cloned
     repository. Ten years of the SQLite project's discussions —
     averaging 2 or 3 dozen posts per day — compress down to just
     35 MB of space in a Fossil Forums repository.

  *  Fossil Forums use [https://sqlite.org/fts3.html | SQLite's powerful
     FTS4 full-text search engine]. If your project currently uses a
     mailing list for discussions, this means you are no longer reliant







|



|







11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

  *  Third-party discussion forum and mailing list software tends to be
     difficult to install, set up, and administer.  Fossil Forums aim to
     be as close to zero-configuration as is practical.

  *  Posts are stored in the Fossil repository using the same
     [./fileformat.wiki | block chain technology] that Fossil uses to
     store your check-ins, wiki documents, etc. Posts sync to cloned
     repositories in a tamper-proof fashion.

  *  Because of Fossil's [./delta_format.wiki | delta compression
     technology], discussions add little to the size of a cloned
     repository. Ten years of the SQLite project's discussions —
     averaging 2 or 3 dozen posts per day — compress down to just
     35 MB of space in a Fossil Forums repository.

  *  Fossil Forums use [https://sqlite.org/fts3.html | SQLite's powerful
     FTS4 full-text search engine]. If your project currently uses a
     mailing list for discussions, this means you are no longer reliant
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64












65
66
67
68
69
70
71
     them with other Fossil artifacts using short internal links: link
     to forum threads from a [./tickets.wiki | ticket], link to a wiki
     document from a forum post, etc. These links are internal and
     managed by Fossil itself, so links never become invalid simply
     because your third-party forum software or mailing list search
     engine changed its URL scheme.

  *  Forum permissions use the same role-based access control mechanism
     as Fossil itself.
     
  *  Since Fossil has an [./fileformat.wiki | open and well-documented
     file format], your discussion archives are truly that:
     <em>archives</em>. You are no longer dependent on a third-party
     piece of software or service sticking around. Should you choose to
     stop using Fossil, you can easily extract your discussion traffic
     for transfer to another system.

  *  Posts can be marked up using Fossil's existing [/md_rules |
     Markdown] and [/wiki_rules | Wiki] markup languages. No longer must
     you choose to restrict your discussion forums to plain text only
     (good for security) or to allow HTML-formatted MIME email (good for
     complex discussions). Fossil Forums provide <em>enough</em>
     formatting without giving up security.














<h2>Setting up a Fossil Forum</h2>

<h3>Permissions</h3>

Fossil forums use the same role-based access control mechanism as







|
|
|













>
>
>
>
>
>
>
>
>
>
>
>







42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
     them with other Fossil artifacts using short internal links: link
     to forum threads from a [./tickets.wiki | ticket], link to a wiki
     document from a forum post, etc. These links are internal and
     managed by Fossil itself, so links never become invalid simply
     because your third-party forum software or mailing list search
     engine changed its URL scheme.

  *  The forum uses the same role-based access control mechanism as
     Fossil uses for all other accesses.

  *  Since Fossil has an [./fileformat.wiki | open and well-documented
     file format], your discussion archives are truly that:
     <em>archives</em>. You are no longer dependent on a third-party
     piece of software or service sticking around. Should you choose to
     stop using Fossil, you can easily extract your discussion traffic
     for transfer to another system.

  *  Posts can be marked up using Fossil's existing [/md_rules |
     Markdown] and [/wiki_rules | Wiki] markup languages. No longer must
     you choose to restrict your discussion forums to plain text only
     (good for security) or to allow HTML-formatted MIME email (good for
     complex discussions). Fossil Forums provide <em>enough</em>
     formatting without giving up security.

  *  Fossil forums integrate with third-party [mail transfer
     agents][MTA]. If you've got mail service configured on the server
     hosting your Fossil instance, it can send notifications of new
     posts to interested forum users, complete with message content for
     those that prefer to visit the forum only when they need to post
     something.

  *  Because Fossil accepts forum posts only via the web UI, it is
     inherently [./antibot.wiki | protected against bots].

[MTA]: https://en.wikipedia.org/wiki/Message_transfer_agent


<h2>Setting up a Fossil Forum</h2>

<h3>Permissions</h3>

Fossil forums use the same role-based access control mechanism as
80
81
82
83
84
85
86






















87
88
89
90
91
92
93
     into the block chain immediately without being held for moderation.
  *  <b>Moderate</b>: User gets buttons on posts which allow them to
     either delete or approve posts held for moderation. User also gets
     access to a page (<tt>/modreq</tt>) showing the list of pending
     moderation tasks.
  *  <b>Administer</b>: User can grant <b>Write Trusted</b> permission
     to another user, or revoke it. (Currently unimplemented.)
























<h3>Single Sign-On</h3>

If you choose to host your discussion forums within the same repository
as your other Fossil-managed content, you inherently have a single
sign-on system. Contrast a mailing list or a third-party forum system,







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
     into the block chain immediately without being held for moderation.
  *  <b>Moderate</b>: User gets buttons on posts which allow them to
     either delete or approve posts held for moderation. User also gets
     access to a page (<tt>/modreq</tt>) showing the list of pending
     moderation tasks.
  *  <b>Administer</b>: User can grant <b>Write Trusted</b> permission
     to another user, or revoke it. (Currently unimplemented.)

By default, no Fossil user has permission to use the forums except for
users with Setup and Admin capabilities, which get these as part of the
large package of other capabilities they get.

For public Fossil repositories that wish to accept new users without
involving a human, go into Admin &rarr; Access and enable the "Allow
users to register themselves" setting. You may also wish to give the
`anonymous` user category the Read Forum (2) and Write Forum (3)
capabilities: this allows people to post without creating an account
simply by solving [./antibot.wiki | a simple CAPTCHA].

For a private repository, you will likely wish to give the "23"
capability pair to the `reader` user category instead.

For either type of repository, you are likely to want to give at least
the Write Trusted (4) capability to the `developer` user category.

By following this advice, you should not need to tediously add
capabilities to individual accounts, except in atypical cases, such as
to grant the Moderate Forum capability (5) to an uncommonly
highly-trusted user.


<h3>Single Sign-On</h3>

If you choose to host your discussion forums within the same repository
as your other Fossil-managed content, you inherently have a single
sign-on system. Contrast a mailing list or a third-party forum system,