12306 - [FEATURE] UI: Message annotations.

Status: NEW

(MailNews Core :: Backend, enhancement)

Description

[Matthew Tuck [:CodeMachine]]

This is a request to be able to annotate messages.  It should operate in a
similar fashion to bug #12305, which is the equivalent for web pages.

Comment 1

[Matthew Tuck [:CodeMachine]]

Actually, I was going to file another bug on annotating message senders, but
then I realised you might want to annotate just about anything.

Anyway, as you may know annotations were suggested by JWZ in his Intertwingle
proposal (http://www.mozilla.org/blue-sky/misc/199805/intertwingle.html),
although this seems orthogonal to the link traversal part of this, although
quite related.

You might see annotations for the sender, for the sender's domain, etc, and
you'd probably want to separate in the popup whether this is just for this
message, for the whole sender, etc.  I think the "content alteration"
possibility of bug #12305 is possible under this as well, but only on a message
by message basis.

Comment 2

[Matthew Tuck [:CodeMachine]]

You need to put HELP WANTED in the whiteboard for it to come up in the query
link on the mailnews page.  =)

Comment 3

[Phil Peterson]

Thanks for looking out for me (I wouldn't want to send these bugs into
oblivion), but I think in this instance you're mistaken.

Comment 4

[Matthew Tuck [:CodeMachine]]

Certainly looks that way now.  I'm sure it used to be the other way though.  =)

Comment 5

[Matthew Tuck [:CodeMachine]]

You should be able to define your own "annotation domain" (ie the messages the
annotation applies to) rather than mailnews trying to work out the possible
scopes for you, because there's too many.

For example, you might want to define an annotation for all .com.au senders, or
all people "to or cc" a .gov or .mil.  That's the sort of flexibility I'm
referring to, because you just know someone will want it.

These annotations can be used as popups or reminders.  It would be really great
to get a message saying "This guy called you a butt-kisser in public."  =)

Comment 6

[Matthew Tuck [:CodeMachine]]

The annotation scope/domain should probably be defined using the same selection
panel as is used for filters, for reusability reasons.

Comment 7

[Phil Peterson]

Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey
bug tracking radar. Even though these bugs are not "open" in bugzilla, we
welcome fixes and improvements in these areas at any time. Mail/news RFEs
continue to be tracked on http://www.mozilla.org/mailnews/jobs.html

Comment 8

[Phil Peterson]

Reopen mail/news HELP WANTED bugs and reassign to [e-mail]

Comment 9

[mozilla.old.2]

I think we should make sure, that this info is stored in any
standards-conformant way. For example, I am happy to have *all* important info
on the IMAP server (safer, cross-platform). And not to be bound to any special
mail reader.

How about this: Create the annotation as a reply with special headers. Maybe the
"To:" field could contain a special value, too, so that the user can easily see
even in other mail readers, that this is an annotation.

It wouldn't be easy to get the configurable scope thing into that scheme, but it
should be possible, I think.

Comment 10

[mozilla.old.2]

This feature looks very cool. My experience is zero, but I will browse through
the source and see, if I can do something for this. Any hints/help welcome.

Comment 11

[Matthew Tuck [:CodeMachine]]

Is it "standards compliant" to use non-standard headers?

I don't see you could immediately store it in messages in IMAP, since the most
likely use is for attaching to senders, not messages.  But I don't know IMAP.
And you're still going to have a local storage mechanism for caching (I believe
IMAP still has offline mail?) and non-IMAP implementations.

Comment 12

[mozilla.old.2]

>Is it "standards compliant" to use non-standard headers?
I think so (given, that the standard headers are included). Am I wrong?

>since the most likely use is for attaching to senders, not messages.
The opposite is true for me.
Anyway, I think, annotations are initiated through messages, so we could create
a reply with special headers, storing the "general scope".

>And you're still going to have [...] non-IMAP implementations.
Sure, this should work fine. IMAP was just an example/argument.

Comment 13

[mozilla.old.2]

OK, I'll *try* to dig in. URL is http://www.bucksch.com/mozilla/12306.
Help/comments etc. appreciated.

Comment 14

[lchiang]

Hi Ben, if you are going to try to implement this feature, you may want to
assign the bug to you :-)

Thanks!

Comment 15

[Matthew Tuck [:CodeMachine]]

Sorry, I didn't read your original message properly, I thought you were talking
about adding headers to messages, rather than separate replies.

I think it's better to create a special folder that contains the annotations as
a message each.  This would allow mailers not supporting this to at least
support the display of annotations easily, and can delete them.  I think
replies are not the best since they could confuse users and they also imply that
an annotation is fixed to a specific small set of messages, which it shouldn't
be.  This folder should still be displayable through compliant mailers, since
you could centrally read and maintain the annotations.  Ideally you'd also be
able to get a list of messages this annotation applies to.

I think the presence of an annotation should be a column containing an
exclamation mark of similar.

My idea of annotations is a window that pops up.  You would see a scope title
and then the text, eg:

--- From sender [e-mail] ---

blah blah

-- This message ---

blah blah

---
Add Annotation   Delete Annotation

etc.

Adding davidmc who might be interested and have suggestions.

Comment 16

[mozilla.old.2]

I think, we're talking about different things. I'm thinking of annotations to
exactly one message. This would mean, that they must be stored near the message,
too. (1) This enables non-Moz-MUA-users to easily see the annotation (2) It
keeps related data together (e.g. all info concerning project XY can be archived
in one step).
I see your general scope as an extention to this. An annotation folder would be
appropriate for your comment from 08/23/99 19:26, I think.

Comment 17

[Matthew Tuck [:CodeMachine]]

Yes, and the desire to see a general facility implies that you should have a
general mechanism (ie forward compatible), not two different ones.

Even having only message annotation, I'm still not sure it's the best, for
reasons like there is no easy way to find all annotations centrally, and it
implies that they are replies, which they're not.

Comment 18

[mozilla.old.2]

Why is my proposal not forward compatible? You just store the annotation in
another folder. But you do (1) store more info (the scope) and (2) have to get
the info from the user and (3) have to implement the events incl. handlers.

Please go ahead any tell me your complete concept so I can keep it in mind or
build it in.

> there is no easy way to find all annotations centrally
Why should you want to?

Comment 19

[mozilla.old.2]

I think, I wasn't clear enough: You could easily store message-related
annotation in the message folder and annotation with a general scope in a
special annotations folder, as you suggest.

Comment 20

[davidmc]

See ref to "transclusion" in Ted Nelson's Xanadu, at
http://www.xanadu.net/zigzag/ and
http://www.byte.com/nntp/joncon?comment_id=1701

I mention these only to give you a place to go look and have even more ideas than
you currently have; I don't mean to patronize, or imply Nelson's ideas are better
than anyone else's, or that yours and mine are not in fact better.  It's just
grist for the mill.  I will add another comment in a moment.

Comment 21

[davidmc]

I have written some things before about the variety of techniques
to achieve the effect of associating two pieces of data; so the idea
of annotation is a particular application of this general notion.

I expect that many folks easily come up with very similar ideas about
what is desirable to see in a user interface that supports annotation
and can usefully merge together disparate data sources.  So none of
my comments are ever aimed at trying to say something first so I can
show the novelty of my thinking. :-)  Instead my comments aim to
groan about practical aspects of plumbing, and to reduce any problems
and risks that can arise from specific designs that are suggested.

Let's stipulate that the act of storing annotations someplace is not
very hard, and that if you take care to use a schema-less database
of some kind or another, then you leave yourself open at all times to
add new kinds of annotation without breaking old formats.

So it is going to be the other effects that are hard to control, and
the common theme is all the things that can go wrong with maintaining
synchronization either between base data and annotation data, or
between annotation data and archives of annotation data.  It seems
this has already been discussed by Ben and Matty.  Please go on doing
this analysis, because the hard part will be assigning priorities
about what things matter more, because some choices will be necessary.

A particular design has to arise out of some weighting of which things
matter most to you, whether it is shared access, or resistance to bad
data or out-of-sync data, or ease and cheapness of archiving, or tidy
presentation in a rational way to end users, etc, etc.

So my input will tend to focus on adding shades of gray on such stuff,
and maybe a little on the implications of storage choices.  So what
do you want me to say?  What do you see as problems?  What questions
do you want answered more than others right now?

Comment 22

[mozilla.old.2]

I've read the articles, but I couldn't see any relation to our problem, since
they propose are completely new worlds.

What do you mean by "schema-less database" any how would it look like?

As I already pointed out, I think, the location and format of storage is
essential. Although, of course, these are not the only key attributes.
Extensible designs are what I normally vote for, too. If anybody could give
ideas how to do create this, I'd like to hear that. Real extensible design are
hard to create, since you have to make things possible, which you can't think
of.

At the moment, all "extentions" I can think of are the proposals of Matty,
which 	I respect as fully valid. I've just no use for them and no motivation to
implement them, since I think, that they need a lot of _additional_ work to
message annotations. I still have no concrete impression, what Matty thinks, how
to implement it, but as far as I see it, there's no problem in extending message
annotation as I planned them to the more general messaging annotations
(including Matty's proposals).

The only problem I see at the moment is, as David pointed out, syncronisation. I
think, we shouldn't store annotations in the original message (since then, it
wouldn't be "original" anymore :-)), so we need to keep track of message
copying/deleting. The real problems in implementing this are (1) understanding
the current code and (2) the danger of forgetting something.

Please see the homepage for the project, too.

Comment 23

[mozilla.old.2]

If there're any comments on the design, please articulate them now, since I'm
already evalutaing the implementation.

Comment 24

[davidmc]

> I've read the articles, but I couldn't see any relation to
> our problem, since they propose are completely new worlds.

Sorry, I thought Nelson's "transclusion" idea would suggest some
avenues of thought.  Ignoring that, the general idea concerns how
to join two separately stored pieces of data as if they had stored
together in the first place.

Annotation amounts to giving objects new attributes.  There's no
reason why attributes could not be stored just about anywhere.  So
the annotation model will be well-defined if you specify in what way
an annotation db provides addtitional attributes for remote objects.

> What do you mean by "schema-less database" any how would it look like?

That means the number of attributes for any object is unbounded, so you
can always add more.  A database design using a schema usually does so
in order to develop fixed performance strategies based upon knowing that
extensions will never occur.  This trades off extensibility for speed and
space optimization, neither of which are that critical any more today,
because hardware is much faster and capacity is much greater.

> As I already pointed out, I think, the location and format of storage
> is essential. Although, of course, these are not the only key attributes.

I think the interface is more important than the location and format.
This actually makes both of them mutable and extensible, which is part
of the point when one is extending objects with new attributes.

Personally I care a lot about formats, but I never seem to meet anyone
who actually understands any format designs I create, to the extent
they see why I made certain choices.  So I view emphasis on format with
some suspicion, since I expect someone to then settle for a fixed system
that holds no interest for me.  If you pick a non-extensible format, then
I would tend to ignore everything after that point.

> Extensible designs are what I normally vote for, too. If anybody could
> give ideas how to do create this, I'd like to hear that. Real extensible
> design are hard to create, since you have to make things possible,
> which you can't think of.

You might check out my months stale IronDoc site, which has much more
material on database stuff than you'd probably like to read:

http://www.best.com/~mccusker/irondoc/irondoc.htm
http://www.best.com/~mccusker/irondoc/query/whatis/qwfe.htm

One main theme in my IronDoc work was extensibility.  So I have a notion
I know a lot about this, but I lack the verve to play an authoritarian on
the topic.  However, the main techniques involved are using attribute
value pairs, and designating almost everything using names so that the
set of denotable things is both very large and flexible.

> At the moment, all "extentions" I can think of are the proposals
> of Matty, which I respect as fully valid.

I guess I didn't grasp them when I read the first time.

> I've just no use for them and no motivation to implement them, since
> I think, that they need a lot of _additional_ work to message
> annotations. I still have no concrete impression, what Matty thinks,
> how to implement it, but as far as I see it, there's no problem in
> extending message annotation as I planned them to the more general
> messaging annotations (including Matty's proposals).

I keep the position that actually storing annotations is a much less
delicate problem than how to control the usage of these with respect
to the remote content that is being annotated.

> The only problem I see at the moment is, as David pointed out,
> syncronisation. I think, we shouldn't store annotations in the
> original message (since then, it wouldn't be "original" anymore :-)),
> so we need to keep track of message copying/deleting.

Annotations should be stored separately.  Each message has an identity,
which distinguishes it from another.  Each annotation would also say
the identity of the message which it annotates, so one can look up
whether any given message has some annotation.

> The real problems in implementing this are (1) understanding
> the current code and (2) the danger of forgetting something.

There is also a danger of not having a definite plan, since some things
cannot work well by following the algorithm of removing annoyances as
they arise.  Sometimes the process does not converge on a done state
when one plans to fix conflicts as they come up in practice, instead
of defining how conflicts cannot happen in the first place.

I might not be able to say much more about this problem, but I might
kibitz at random.  I'm confused about how the implementation can be
underway when I don't see that the design has been roughed out.  But
maybe I just don't get your normal coding practice.

Comment 25

[mozilla.old.2]

I think we're blowing up BugZilla, it is really is no discussion platform.
Additionally, I get the impression, we're all talking about different things. We
should look for another medium.
What about Chat? I'm pretty tired right now (it's 0:28 here), what about
tomorrow morning (WST)? I'm usually on #mozilla, too.
I hope to be able to read the docs you pointed me to. Please be sure to read
this thread and the project homepage (URL field) again. I'll do the same.

Comment 26

[davidmc]

It would be okay to discuss in n.p.m.mail-news. I have never used any kind of
chat because I prefer slower mediums, and dislike anything which requires that my
attention track something.  It's as if I detest immediacy. :-)  I am happy not
existing as far as chat is concerned.

Comment 27

[Matthew Tuck [:CodeMachine]]

Ben the reason I say "not forward compatible" is that I think you should have a
general mechanism and therefore if you made them replies you couldn't easily
change it to later where all messages are in the annotations folder.  Perhaps
it's not the best terminology to use.

I don't really care what you do in the UI since it's easy to change later, but
when I think about placing one type of annotation in one place and another in
another, alarm bells start going off in my mind.

I can see it might be a problem to put a header on the annotation, and then need
to work out what folder it's in.  David could say more about what's involved
here.

As for central viewing of annotations, I can imagine various situations where I
might want to browse the annotations centrally, such as deleting old
annotations.  Furthermore, having an annotation is a way of getting into the
message as well - if you "opened" it, you might go to the message.  It might be
easier to find your message by browsing the annotations than all the messages.

Comment 28

[mozilla.old.2]

If you store all annotations as special messages in one folder, they're not very
different from replys as well. Replys are just new messages with a reference to
the original one and maybe quoted text. And this is exactly, what we want (at
least what I think we want).

> when I think about placing one type of annotation in one place and another in
> another, alarm bells start going off in my mind.

Could you please explain that further? I see no real problem there.

> As for central viewing of annotations, I can imagine various situations where
> I might want to browse the annotations centrally, such as deleting old
> annotations.

Why should you want to look for annotations to delete. I look for messages (and
related annotations) to delete or, and that's key here, for entire folders of
messages to delete/archive.

> It might be easier to find your message by browsing the annotations than all
> the messages.

As pointed out on the homepage, it is possible to change the icon of the message
to indicate the annotation.
For attachments, it would make much more sense to store them separately than for
annotations (size), but they're stored in the messages, too. And I consider it
as good.

I want different folders being _completely_ separated, including all related
data.

How do you want to treat non-Moz-MUAs? If you store all annotation in one
folder, it's nearly impossible for the user to recreate relations manually.

Comment 29

[mozilla.old.2]

> when I think about placing one type of annotation in one place and another in
> another, alarm bells start going off in my mind.
Could you please explain that further? I see no real problem there.

I think I should make that clearer. We're talking about two completely different
types of annotations here. Apart from storage, message annotations have more in
common with web annoantions than the general scope messaging annotations.

Message annotation are attached just to an object, while the general scope
annotations can be considered as annotations to expressions.

The only things they have in common are the nature of being a text (message) and
that they're maybe a reaction of a message (a kind of reply) with quotes.

Comment 30

[mozilla.old.2]

David, I must admid I fear a discussion on usenet. They typically need 2 weeks,
and I have, as bad as this sounds, not the time for that.

I both don't what to wait for comments several weeks (until the thread is
closed) and want this to be shipped with 5.0 and IIRC, the deadline for features
is 19. this month.

But this doesn't mean I dislike design or discussion. This is the reason I
discuss with you (both).

It's just the medium which makes problems, because there's no threading.

Comment 31

[davidmc]

If bugzilla is like the old Netscape bugsplat, then eventually the bug text will
fill up and truncate any additions, which can only be fixed by editing down the
body of the bug report.  This is just a warning to help explain, in case someone
sees what looks like this behavior; I don't know if limits still apply.

Is the propagation delay for usenet a problem?  Or do you just worry that you
must actually give folks more time when discussing in that venue?  I was just
looking for a place to exchange dialog with you; I'm not concerned about whether
other folks get their own say.  They can either keep up to your pace or you can
ignore them; there's no need to let anyone hold you back.  Also, you can never
tell when somebody might make what seems a very useful suggetion.

Comment 32

[Matthew Tuck [:CodeMachine]]

> If you store all annotations as special messages in one folder, they're
> not very different from replys as well.

Not using the standard headers would cause non-compliant mailers to not show
them as replies - I think this is a good thing.  I don't see a real problem with
not being able to find annotations from a message with a non-compliant mailer,
if they want to, they can add the feature.  Putting it a central folder reduces
the folderspace pollution from the non-standard extension.

Though I think the main question is which folder they're stored in.

> Could you please explain that further? I see no real problem there.

I don't like the idea of one type of annotation being stored as replies in the
same folder, and others just being standalone messages in another.

> Why should you want to look for annotations to delete. I look for
> messages (and related annotations) to delete or, and that's key here,
> for entire folders of messages to delete/archive.

Not so much for one-message annotations, but certainly for general annotations
you'd want to do that.

I guess there is a distinct difference though.  Because per-message annotations
are linked to a single message they can and should be deleted along with the
message.

> As pointed out on the homepage, it is possible to change the icon of the
> message to indicate the annotation.

Yes but what if you have a thousand messages in tens of folders with an
annotation you could quickly recognise?  A search facility could certainly help,
but I think direct browsing is still desirable.  This can probably be done with
some sort of virtual folder with your way though.

> For attachments, it would make much more sense to store them separately
> than for annotations (size), but they're stored in the messages, too. And
> I consider it as good.

But attachments ARE part of the message, and they have identity issues (you've
seen bug #9413).  They won't necessarily be stored "in the message" though,
that's up to the message store.  Obviously it has to look like it is over POP
and IMAP though.

> I want different folders being _completely_ separated, including
> all related data.

What about annotations whose scope is within a folder?  Do these get stored in
the folder as standalone?  What if it applies to a folder or it's subfolder?
Does it get stored in the highest folder?  These are all possibilities, but the
make it more complicated.

You can only evaluate this is terms of user usage.  For compliant mailers, the
issue is simplicity and efficiency of implementation, since they can do anything
in the UI.  For non-compliant mailers, the issue is how it will appear to the
user.

I think efficiency needs to be discussed, particularly over IMAP.  What
operations are efficient?  How easy would it be to locate an annotation for a
message in a central folder?  In the same folder?

> How do you want to treat non-Moz-MUAs? If you store all annotation in
> one folder, it's nearly impossible for the user to recreate relations
> manually.

I'm not sure I understand what you mean.  What relations?

Comment 33

[mozilla.old.2]

> Not using the standard headers would cause non-compliant mailers to not show
> them as replies - I think this is a good thing.

I do not.

> I don't see a real problem with
> not being able to find annotations from a message with a non-compliant mailer,
> if they want to, they can add the feature.

LOL

> Though I think the main question is which folder they're stored in.

At the moment. But, as David indicated, we should concentrate on other goal,
too.

>> Could you please explain that further? I see no real problem there.
> I don't like the idea of one type of annotation being stored as replies in the
> same folder, and others just being standalone messages in another.

This is no explanation, this is a statement.

> I want different folders being _completely_ separated, including
> all related data.

> What about annotations whose scope is within a folder?  Do these get stored in
> the folder as standalone?  What if it applies to a folder or it's subfolder?
> Does it get stored in the highest folder?  These are all possibilities, but
> the make it more complicated.

I'm speaking of annotations to exactly one message. Not Folders, not Recipients.
Every bjond that, I consider as belonging to your general scope idea, which I
have no time to implement. Deadline is in 11 days!

> I think efficiency needs to be discussed, particularly over IMAP.  What
> operations are efficient?  How easy would it be to locate an annotation for a
> message in a central folder?  In the same folder?

Keeping messages and annotations together would be far more efficient, because
it's only one folder which has to be connected to. But I don't think, that'S so
much an issue.

>> How do you want to treat non-Moz-MUAs? If you store all annotation in
>> one folder, it's nearly impossible for the user to recreate relations
>> manually.
> I'm not sure I understand what you mean.  What relations?

The message, to which the annotation refers. If you store all annotations in one
folder and you have, say 50 annotations to 50 of 1000 messages, how qould the
user be able to see, (1) to which message the annotation refers or (2) that
there's an annotation to the message he's viewing? If annotations are replys in
the same folder, *any* MUA can present the relations correctly.

Comment 34

[Matthew Tuck [:CodeMachine]]

>> I don't like the idea of one type of annotation being stored as replies in
>> the same folder, and others just being standalone messages in another.
> This is no explanation, this is a statement.

The point is that general mechanisms tend to be easier to implement, understand,
 maintain and tend to have less bugs, as opposed to many case mechanisms, or
general mechanisms with special cases.  Putting them all in one place would make
it more general since getting an annotation is simpler.

What I'm concerned about is a design decision now can't be easily changed later
if people are using this feature.  I don't think 11 days is enough time to
consider the issues.

> I'm speaking of annotations to exactly one message. Not Folders, not
> Recipients.  Every bjond that, I consider as belonging to your general
> scope idea, which I have no time to implement.

I know, but I think it's important to hash out the general design now before
implementing the subset.  Hence I think it's better if the message annotation
feature is designed to try to be consistent with all messaging annotations.

> Keeping messages and annotations together would be far more efficient,
> because it's only one folder which has to be connected to. But I don't
> think, that'S so much an issue.

I imagine a lookup on one folder would be, but the question is by how much (is
it worthwhile as an optimisation on this case)?  Are searches on multiple
folders in general inefficient?  Does IMAP have a high-level primitive to do it,
allowing IMAP servers to be efficient on multi-folder searches?  How easy is it
to look one up from the other?

> how qould the user be able to see

By looking at headers, if interested.

> there's an annotation to the message he's viewing? If annotations are
> replys in the same folder, *any* MUA can present the relations correctly.

I know, but I don't think this is desirable, since non-compliant mailers can't
distinguish between a reply and an annotation.  I guess it's a touchy-feely
impression.  I'm not even sure I care about non-compliant mailers, since we're
hardly going to break them.

Comment 35

[mozilla.old.2]

Discussion is going on in n.p.m.mail.news
http://x45.deja.com/viewthread.xp?AN=522575868&search=thread

Changed "Component" to "Back End"

Comment 36

[mozilla.old.2]

Attachment: 1/6

Comment 37

[mozilla.old.2]

Attachment: 2/6

Comment 38

[mozilla.old.2]

Attachment: 3/6

Comment 39

[mozilla.old.2]

Attachment: 4/6

Comment 40

[mozilla.old.2]

Attachment: 5/6

Comment 41

[mozilla.old.2]

Attachment: 6/6

Comment 42

[mozilla.old.2]

Attachment: 7/6 (missed one)

Comment 43

[mozilla.old.2]

The attachments represent the current state of work.

Work is haltet at the moment in favor of bug #13678.

Comment 44

[mozilla.old.2]

Moving to M20 till I have a more concrete impression of timeline.

Comment 45

[Ben Bucksch (:BenB)]

Dependency on bug #13678.

Comment 46

[Ben Bucksch (:BenB)]

Mass-LATER

Comment 47

[lchiang]

Ben - is this LATER because you can't work on this now?  If so, perhaps add to 
"helpwanted" list?   Just trying to understand since usually "resolved" (even 
bugs at a later resolution) bugs tend to get lost because no one searches for 
bugs that are resolved.  Thanks.

Comment 48

[Ben Bucksch (:BenB)]

agreed. REOPEN, helpwanted

Comment 49

[lchiang]

I think the query for helpwanted may also search for assigned to as: 
[e-mail]. You may want to change the assignee to that and then add 
yourself to the cc: list.

Comment 50

[Ben Bucksch (:BenB)]

Lisa, you're speaking about <http://www.mozilla.org/mailnews/jobs.html>? It does
show up in the query linked from there.

Comment 51

[lchiang]

You are right, Ben.  I was just thinking that if the assignee showed someone's 
name, a person looking / glancing through the list may think that the bug is 
already taken.  This is just me being picky :-)

Comment 52

[Ben Bucksch (:BenB)]

I'm still a bit interested in this bug, but not in the moment, so yuo may be
right... REASSIGNing

Comment 53

[lchiang]

Moving feature bugs to target milestone "Future" for next release consideration.

Comment 54

[Peter K. Guldbaek]

*** Bug 183002 has been marked as a duplicate of this bug. ***

Comment 55

[Greg K.]

See also the IMAP Annotation draft at
<http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-imapext-annotate-00.txt>.

Comment 57

[zug_treno]

See also Thunderbird bug 254739.

Comment 58

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 60

[Nobs Wolf]

Is anyone still working on this? 

I used the addon Xnotes for that purpose, but this project kinda died and is not usable with thunderbird v3 any more.

I would really appreciate if this feature would be added soon.

And BTW: I don't think using IMAP features for this is a good idea because it should work with POP as well.

Comment 64

[David Teller [:Yoric] - still alive but not very active]

Wow, this bug had only 5 digits. Would be great if someone could make it work :)

Comment 66

[Martin Sch]

Very often I have the need to comment emails in my inbox for my own use.
This is helpful if I later look into the mail.
For example I have a mail with the text "ok, I'll promise I will do it" and I would like to add the note "asked him on phone to give me 1000 dollars".

Also, it would be nice to mark the mail with a date, for example how long it is valid. Let's say I get a mail with an invitation to a party on 1mar2013, so I would keep that mail and mark it to be deleted on 2MAR2013.

This could be done with some extra headers which are stored with the mail.
For example 
    X-Mozilla-Comment: asked him on phone to give me 1000 dollars

Comment 69

[Wayne Mery (:wsmwk)]

The rfc backend which could support this in a shareable way is bug 288514.

The "standalone notes" complement to this bug is bug 116945.

Comment 70

[Germano Massullo]

I was filling a new feature request, when I found this one that may be the same. I attach the text hereunder

=================

Sometimes it can be useful to be able to tag an email with a searchable tag.
For example you receive a message that has an subject that does not reflect correctly the message content. So you may want to add a tag / description to it, so that you can easily search it, avoiding to use the "search in message body" tool which is much slower

Comment 74

[GerryT]

I would like to ask for the integration of the excellent post-it/sticky notes feature from Xnote++ into Thunderbird core

Currently, the feature "persistent sticky notes associated to mails" is provided by the excellent add-on XNote++, which is one of the most useful extensions, but which will not be ported to Thunderbird 78+. Since sticky notes are a real productivity booster and a competitive advantage (e.g. over MS Outlook), I would like to ask you to integrate it into Thunderbird core.

• It is a brilliant idea to have persistent yellow post-its/sticky notes attached to individual emails. It allows for dozens of productive uses such as info on conversation follow-ups, info whether invoices were paid, and many more. This feature substantially increases productivity when working with emails.
• The current implementation of Xnote++:
  ** feels like an integral part of Thunderbird
  ** is nicely integrated with the tagging feature of Thunderbird by adding the XNote tag
  ** works flawlessly for many years and it is ranked 5/5 stars
  ** provides a feature which does not exist in competing email clients (e.g. MS Outlook)
  ** XNote++ it is a featured extension.
• An integration into core Thunderbird would also allow for searching notes (which Xnote currently does not provide) and would avoid dataloss from users of the current add-on.

https://addons.thunderbird.net/en-US/thunderbird/addon/xnotepp/
https://www.froihofer.net/en/xnote.html

Comment 75

[GerryT]

Since the current Xnote++ addon requires a major rewrite to be compatible with TB 78, there is now an entry at bountysource to finding someone who would like to pick up the task to port this important extension over to TB78+

I hope there will be enough backers to motivate someone to do the porting:
https://www.bountysource.com/issues/92160540-add-support-for-thunderbird-78

Comment 76

[GerryT]

There is some effort by Martins Lazdans to port Xnote++ to TB78:
https://addons.thunderbird.net/de/thunderbird/addon/qnote/
https://cleidigh.github.io/ThunderKdB/xall/x68/987900-qnote/987900-qnote-details.html

Wouldn't this post-it feature be something that it worth being integrated into Thunderbird core?